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Preface 


Enterprise  Resource  Planning  (ERP)  systems  are  configurable,  commercial  off-the-shelf  software 
packages  designed  to  enable  an  organization  to  integrate  operational  and  management  processes 
across  a  broad  range  of  internal  business  activities,  including  procurement,  accounting,  finance, 
and  human  resources.  ERP  programs  tend  to  be  very  large,  involve  a  multitude  of  stakeholders, 
and  take  a  long  time  and  considerable  cost  to  implement.  Such  programs  often  cost  more  and 
take  longer  than  anticipated,  and  some  do  not  deliver  the  intended  benefits  when  completed. 
Careful  planning  is  critical  to  their  success. 

This  report  emanates  from  a  RAND  Project  AIR  FORCE  Resource  Management  Program 
fiscal  year  2012  project,  “Why  Do  Big  Air  Force  and  Department  of  Defense 
Automation/Enterprise  Resource  Planning  Systems  Fall  Short?”  This  research  was  sponsored  by 
Lt.  Gen.  Christopher  D.  Miller  (ret.),  former  Deputy  Chief  of  Staff  for  Strategic  Plans  and 
Programs,  Headquarters  U.S.  Air  Force;  and  Dr.  Jamie  M.  Morin,  Assistant  Secretary  of  the  Air 
Force  for  Financial  Management  and  Comptroller.  The  project  had  two  complementary  research 
goals.  The  first  was  to  understand  the  key  early  planning  issues  associated  with  ERP  programs 
and  to  provide  the  Air  Force  with  recommendations  for  improving  this  planning.  The  second 
goal  was  to  understand  how  these  key  early  planning  issues  may  be  manifested  during  ERP 
program  execution  and  to  provide  recommendations  for  improving  early  assessments  of  such 
programs.  This  analysis  was  conducted  between  October  2011  and  July  2012. 

This  report  is  not  a  “lessons  learned”  case  study  analysis  of  troubled  programs,  but  an 
analysis  of  steps  the  Air  Force  should  take  to  improve  the  success  of  business  transformation,  of 
which  ERP  acquisition  can  be  a  part.  This  report  should  interest  those  involved  in  business 
transformation,  those  involved  in  the  planning  and  development  of  defense  business  systems,  and 
those  concerned  with  the  costs  of  such  systems. 

RAND  Project  AIRFORCE 

RAND  Project  AIR  FORCE  (PAF),  a  division  of  the  RAND  Corporation,  is  the  U.S.  Air 
Force’s  federally  funded  research  and  development  center  for  studies  and  analyses.  PAF 
provides  the  Air  Force  with  independent  analyses  of  policy  alternatives  affecting  the 
development,  employment,  combat  readiness,  and  support  of  current  and  future  air,  space,  and 
cyber  forces.  Research  is  conducted  in  four  programs:  Force  Modernization  and  Employment; 
Manpower,  Personnel,  and  Training;  Resource  Management;  and  Strategy  and  Doctrine. 

Additional  information  about  PAF  is  available  on  our  website: 
http://www.rand.org/paf/ 
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Summary 


Information  technology  (IT)  has  come  to  play  an  increasingly  significant  role  in  the  way 
organizations  conduct  business,  evolving  from  a  narrow  tool  for  automation  to  a  potential 
enabler  of  business  transformation. 1  Enterprise  Resource  Planning  (ERP)  systems  are  prime 
examples  of  IT  systems  being  pursued  by  the  Department  of  Defense  (DoD)  to  enable 
transformation  and  improve  efficiency  and  effectiveness.  ERP  systems  are  configurable, 
commercial  off-the-shelf  (COTS)  software  packages  that  enable  organizations  to  integrate 
operational  and  management  processes  across  a  broad  range  of  internal  business  activities.  The 
DoD  and  the  military  services  have  implemented  or  are  in  the  process  of  implementing  several 
ERP  systems  to  enable  business  transformation  goals  and  meet  the  fiscal  year  (FY)  2017 
deadline  for  auditable  consolidated  financial  statements  (Public  Law  99-433,  2010).  The  Air 
Force  is  implementing  two  such  systems,  the  Air  Force  Integrated  Personnel  and  Pay  System 
(AF-IPPS)  and  the  Defense  Enterprise  Accounting  and  Management  System  (DEAMS),  and 
recently  canceled  a  third,  Expeditionary  Combat  Support  System  (ECSS).  These  ERPs  were 
initiated  with  the  intent  of  improving  the  effectiveness  of  the  Air  Force’s  business  functions  and 
providing  operational  support  to  the  warfighter  (e.g.,  through  improved  visibility  and 
management  of  personnel  and  other  assets).  Importantly,  especially  in  an  era  of  constrained 
budgets,  these  ERPs  were  also  intended  to  reduce  the  cost  of  Air  Force  business  functions,  which 
compete  with  operations  and  modernization  for  funds. 

Implementing  an  ERP  system  can  confer  a  range  of  benefits  to  an  organization  (e.g.,  see 
Davenport,  2000;  Eckartz,  2009;  Shang,  2002;  Staehr,  2010).  ERP  systems  promise  to  integrate 
business  functions  and  data  throughout  an  organization;  provide  a  forcing  function  for  process 
transformation;  standardize  software  and  processes;  reduce  development  costs,  schedules,  and 
risks  via  proven  COTS  products;  consolidate  redundant  systems;  retire  obsolete  legacy  systems; 
and  potentially  simplify  sustainment.  However,  successful  implementation  generally  entails 
significant  business  change  because  ERP  systems  typically  affect  a  large  number  of 
organizational  departments  and  processes.  The  DoD  and  the  private  sector  have  experienced 
numerous  ERP  failures  as  a  result  of  a  misplaced  focus  on  the  enabling  IT  rather  than 
emphasizing  the  broader  business  change  necessary  to  accomplish  the  transformation.  The  scope 
of  change  needed  to  transform  an  organization  is  vast,  and  considerable  attention  must  be  given 
to  the  planning  and  execution  of  the  range  of  activities  associated  with  the  business 
transformation. 

The  Air  Force  asked  RAND  Project  AIR  FORCE  (PAF)  to  review  its  ERP  efforts  and  to 
identify  the  key  early  planning  issues  associated  with  successful  ERP  programs  and  the  ways  in 
which  early  planning,  or  lack  thereof,  might  affect  ERP  program  execution.  PAF  was  also  asked 


1  Business  transformation  definitions  vary,  but  the  term  generally  refers  to  strategic,  enterprise-wide  change  that  has 
a  profound  impact  on  an  organization’s  capabilities,  environment,  and  performance  (e.g.,  see  Capgemini,  2012). 
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to  recommend  options  for  improving  the  Air  Force’s  planning  and  early  assessments  of  ERP 
programs.  Through  review  of  relevant  business  literature  and  interviews  with  a  broad  cross- 
section  of  experts,  stakeholders,  and  senior  government  leaders,  PAF  identified  the  key 
conditions  that  must  be  achieved  to  facilitate  the  success  of  ERP-enabled  business 
transformation,  the  challenges  the  Air  Force  must  address  to  achieve  those  conditions,  and 
options  for  overcoming  these  challenges.  Our  focus  on  ERP  programs  is  not  meant  to  suggest 
that  the  Air  Force  or  DoD  should  view  ERP  systems  as  a  preferred  business  IT  solution  for  all 
circumstances.  In  fact,  as  explained  throughout  this  report,  ERP  systems  have  transformative 
potential  but  are  accompanied  by  a  range  of  conditions  for  success  that  can  be  challenging  to 
achieve.  Finally,  this  report  is  not  a  “lessons  learned”  case  study  analysis  of  troubled  programs, 
but  an  analysis  of  steps  the  Air  Force  should  take  to  improve  the  success  of  business 
transformation,  of  which  ERP  acquisition  can  be  a  part. 

Conditions  for  Successful  ERP-Enabled  Business  Transformation  and 
Challenges  Facing  the  Air  Force 

The  research  team  organized  the  conditions  for  successful  ERP-enabled  business  transformation 
into  five  categories:  business  case,  governance,  business  process  reengineering  (BPR), 
organizational  change  management  (OCM),  and  IT  acquisition.  These  are  not  necessarily 
sequential  categories  of  activities;  many  are  done  simultaneously.  In  each  of  the  five  areas,  the 
team  also  identified  challenges  the  Air  Force  must  address. 

Business  case.  The  initial  purpose  of  a  business  case  is  to  justify  a  project’s  required 
investment;  however,  business  cases  are  also  increasingly  recognized  as  a  planning  and 
management  tool  to  ensure  that  the  business  benefits  sought  are  ultimately  realized.  An  effective 
business  case  should  articulate  the  transformational  goals  and  desired  benefits  that  are  aligned 
with  an  enterprise  business  strategy.  In  the  context  of  this  report,  an  Air  Force  enterprise 
business  strategy  would  address,  at  a  high-level,  how  business  operations  will  support  the 
operational  priorities  of  the  Air  Force.  It  describes  the  principles,  goals,  and  objectives  that  are 
the  foundation  for  an  Air  Force  business  enterprise  architecture.  It  also  is  the  framework  for 
cross-functional  decisionmaking  and  the  adjudication  of  touchpoints  between  functionals. 
Additionally,  it  supports  other  higher-level  strategies  as  required.  The  business  case  should 
include  all  associated  costs,  risks,  and  a  realistic  schedule.  This  requires  a  clear  understanding  of 
both  the  current  (or  “AS-IS”)  environment  and  the  target  (or  “TO-BE”)  environment,  which 
achieves  enterprise  goals.  These  environments  include  processes,  the  organization,  and  IT,  and 
their  understanding  should  include  cost  and  performance. 

The  Air  Force  has  struggled  in  meeting  these  conditions  for  success,  both  in  articulating  an 
enterprise-wide  business  strategy  and  understanding  the  complexities  of  the  AS-IS  and  TO-BE 
business  environments.  This  impairs  its  ability  to  carry  out  the  analyses  and  activities  that  aid  in 
building  a  solid  business  case. 

Governance.  Governance  is  decisionmaking  to  advance  an  organization’s  goals  and 
objectives.  The  governance  structure  and  related  decisionmaking  criteria  should  be  grounded  in 
the  enterprise  business  strategy  and  business  case  and  should  be  as  simple  and  responsive  as 


-  Xll  - 


possible,  with  clearly  defined  authority  and  roles  and  responsibilities,  ideally  led  by  a  single 
person  or  a  small  group. 

The  Air  Force  faces  several  challenges  in  achieving  these  conditions.  These  include  untimely 
or  pro  forma  business  cases  not  aligned  with  an  Air  Force- wide  business  strategy  or  other 
functional  visions;  a  bifurcated  organizational  structure,  with  the  Secretary  of  the  Air  Force 
(SECAF)  responsible  for  business  and  the  Chief  of  Staff  of  the  Air  Force  (CSAF)  responsible  for 
operations/command;  a  multitude  of  influential  stakeholders  operating  within  functional 
stovepipes;  and  conflicting  laws,  regulations,  and  policies. 

BPR.  This  is  defined  as  the  radical  redesign  of  business  processes  to  achieve  dramatic 
improvement  in  business  performance  (Hammer  and  Champy,  2003)  and  has  been  widely 
identified  in  the  literature  as  a  critical  success  factor  for  ERP  implementations.  BPR  should  drive 
the  enterprise’s  processes  toward  achieving  the  benefits  articulated  in  the  business  case.  It  may 
or  may  not  be  enabled  by  IT.  For  BPR  to  succeed,  a  number  of  elements  are  necessary,  including 
leadership  support  and  communication  of  the  vision,  goals,  motivation,  and  importance  of  the 
BPR  project  to  stakeholders.  Senior  leadership,  middle  management,  and  support  staff  must  have 
sufficient  knowledge  of  BPR,  and  the  organizational  and  incentive  structures  must  support  a 
cooperative  environment  that  fosters  communication,  confidence,  and  trust.  Ideally,  IT  processes 
should  be  adaptable  to  minimize  the  need  for  software  customization. 

As  noted  above,  the  Air  Force  has  faced  a  number  of  challenges  in  this  area,  including  the 
lack  of  a  clearly  understood,  broadly  embraced  strategy  with  respect  to  business  transformation 
and  the  need  for  a  better  understanding  of  AS-IS  and  TO-BE  processes.  Indeed,  due  to  the 
multifunctional  and  stovepiped  nature  of  the  Air  Force,  it  is  unlikely  any  individual  has  complete 
knowledge  of  any  process  from  end  to  end.  BPR  is  constrained  by  laws,  regulations,  and 
policies,  potentially  limiting  opportunities  to  change  processes  in  lieu  of  COTS  customization. 

OCM.  This  is  a  term  used  to  describe  an  organization’s  efforts  to  gamer  support  for  changes 
and  encourage  their  adoption.  These  efforts  are  key  to  transformation,  should  be  well  thought 
out,  and  should  have  clearly  defined  implementation  strategies.  Successful  OCM  requires  active 
leadership  support,  synchronization  with  the  business  case,  and  employee  involvement.  Specific 
activities  include  stakeholder  analyses,  fomial  and  informal  communication,  education,  and 
training. 

Air  Force  ERP  programs  have  struggled  to  overcome  organizational  challenges  for  several 
reasons,  including  a  stovepiped  organizational  structure  and  culture,  frequent  leadership 
turnover,  and  limited  options  for  incentives.  OCM  activities  are  frequently  mistimed  or  narrow  in 
focus,  and  there  are  disincentives  to  full  disclosure  of  some  potential  benefits  of  change  (e.g., 
financial  and  personnel  savings)  because  the  functional  owner  may  not  reap  them  or  control 
those  resources. 

IT  acquisition.  If  an  IT  acquisition  is  required,  the  full  range  of  potential  alternatives  should 
be  evaluated  against  their  ability  to  achieve  the  benefits  stated  in  the  business  case.  Should  an 
ERP  prove  to  be  the  appropriate  solution,  specific  expertise  in  this  technology  should  be 
assigned  to  the  program,  either  organically  or  through  independent  consultants  with  appropriate 
expertise  acting  as  trusted  advisers/agents. 
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There  is  a  natural  tendency  for  any  organization  to  focus  prematurely  on  the  candidate  IT 
products  before  more  fundamental  considerations  have  been  articulated  and  decided  upon.  In  the 
case  of  ERPs,  this  is  largely  due  to  the  undeniable  appeal  of  a  COTS  solution  that  purports  to 
provide  “best  of  breed”  functionality  at  lower  development,  training,  and  sustainment  costs 
within  a  shorter  timeframe — and  supposedly  all  at  lower  risk  because  the  system  has  been 
developed  and  deployed  for  other  users.  Unfortunately,  realization  of  these  benefits  is  far  from 
automatic  and  requires  substantial  planning,  expertise,  and  commitment  from  all  stakeholders. 
Choosing  among  multiple  alternative  solutions  requires  an  overarching  business  strategy  and 
architecture  to  guide  scoping  decisions  during  planning  before  program  execution,  which  has 
often  been  absent  in  the  Air  Force.i 2 

DoD  ERP  programs  also  face  some  additional  challenges,  including  constraints  related  to 
service  missions,  national  security  requirements,  and  the  laws,  regulations,  and  policies  imposed 
by  higher-level  organizations.  The  successful  planning  and  execution  of  ERP  programs  require 
specialized  skill  sets  and  knowledge  that  are  not  widely  available,  even  within  most  commercial 
organizations. 


What  Should  the  Air  Force  Do? 

This  analysis  provides  specific  recommendations  for  planning  activities  for  ERP-enabled 
business  transformation.  We  have  grouped  them  in  three  time  phases:  Pretransformation,  in 
which  the  initial  conditions  for  transformation  are  established  on  an  ongoing  basis; 
Transformation,  Preprogram  Initiation,  in  which  all  the  activities  leading  up  to  a  materiel 
decision  are  performed;  and  Transformation,  Post-Program  Initiation,  in  which  activities 
following  the  decision  to  pursue  an  IT  acquisition  are  carried  out. 

Pretransformation.  Before  the  transformation,  the  Air  Force  should 

•  promulgate  and  implement  an  Air  Force  enterprise  business  strategy  and  business 
enterprise  architecture,  developed  by  the  USECAF  in  his/her  role  as  the  Air  Force  Chief 
Management  Officer  (CMO)  and  informed  by  the  Vice  Chief  of  Staff  of  the  Air  Force 
(VCSAF),  to  serve  as  the  framework  and  foundation  for  future  business  transfonnations 

•  document  an  integrated  AS-IS  environment  at  the  Air  Force  enterprise  level  (This 
provides  the  baseline  for  functional  strategies  and  transformations  and  ensures 
coordination  across  functions  leading  to  integrated  solutions.) 

•  establish  Air  Force  enterprise  level  governance  co-chaired  by  the  USECAF  and  VCSAF, 
using  the  Air  Force  business  strategy  as  the  foundation  (Involving  both  the  business  and 
command/operations  parts  of  the  Air  Force  should  facilitate  integrated,  cross-functional 
decisionmaking  to  optimize  the  Air  Force  enterprise.) 

•  expand  CORONA  meetings  or  create  an  equivalent  forum  to  include  assessment  of 
compliance  with  Air  Force  business  strategy.3  (CORONAs  are  ongoing,  so  discussions  at 


i 

~  An  architecture  is  a  formal  blueprint  for  methodically  and  completely  defining  an  organization’s  operational 
processes  and  enabling  environment  (U.S.  Air  Force,  201  lb). 

3 

CORONA  meetings  are  held  three  times  a  year  to  provide  a  venue  for  the  most  senior  leadership  of  the  Air  Force 
to  consider  important  servicewide  issues.  These  meetings  are  chaired  by  the  SECAF  and  CSAF. 
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these  meetings  would  reduce  the  impact  of  senior  leadership  turnover  and  increase 
business  program  stability.  Simultaneously,  it  increases  accountability  in  implementing 
Air  Force  business  strategy.) 

Preprogram  Initiation.  Before  initiation  of  an  IT  acquisition  program,  the  Air  Force  should 

•  develop  a  business  case  following  the  Business  Capability  Lifecycle  (BCL)  format  for  the  IT 
acquisition  consistent  with  enterprise  goals  and  strategy,  and  aligned  with  Air  Force  business 
and  IT  enterprise  architectures  (Carter,  2011).  In  building  the  business  case,  the  Air  Force 
must  place  a  greater  emphasis  on  expected  benefits  and  their  realization.  This  includes: 

-  establishing  business  metrics  to  measure  progress  toward  the  TO-BE  environment 

-  establishing  accountability  to  the  Air  Force  Corporate  Structure  by  factoring 
benefits  realization  into  decisions  on  future  funding  and  program  direction4 

-  considering  benefits-sharing  with  stakeholders  to  provide  incentives  for  better 
disclosure  and  management  of  benefit  realization 

-  linking  benefits  with  specific  changes  to  business  processes,  organizations,  and  IT. 

•  develop  the  transformation  governance  structure  for  decisionmaking  that  advances  the 
goals  of  the  transformation  (This  needs  to  be  done  within  the  context  of  the  Air  Force 
business  strategy  and  should  be  aligned  with  the  Air  Force  enterprise  business 
governance,  which  is  responsible  for  advancing  this  strategy  and  should  be  co-chaired  by 
the  CMO  and  the  VCSAF.) 

•  conduct  BPR  and  develop  TO-BE  business  processes  before  determining  if  a  new  IT 
acquisition  is  appropriate 

•  initiate  appropriate  OCM  activities  as  soon  as  the  decision  is  made  to  pursue  a  business 
transformation 

•  carry  out  a  stakeholder  analysis  to  identify  potential  organizational  pitfalls  and  the 
feasibility  of  achieving  desired  benefits  within  a  proposed  timeline 

•  conduct  a  robust  assessment,  early  in  the  process,  of  IT  infrastructure  and  solution 
compatibility,  data  sources,  structures,  definitions,  and  quality  to  inform  both  BPR  and  IT 
planning  activities. 

Post-Program  Initiation.  After  initiating  the  program,  the  Air  Force  should 

•  decide  whether  changing  the  updated  business  processes  or  customizing  the  system  is 
more  appropriate 

•  focus  OCM  on  achieving  acceptance  of  the  new  technology  and  required 
process/organizational  changes,  frequently  accomplished  by  incentivizing  the  affected 
personnel 

•  update  stakeholder  analyses  and  OCM  plans  (communication,  education,  and  training)  as 
key  decisions  are  made  that  affect  the  trajectory  of  the  overall  transformation 


4 

The  Air  Force  Corporate  Structure,  as  defined  in  Air  Force  Instruction  16-501  (U.S.  Air  Force,  2006),  is  a 
governance  structure  through  which  the  Planning,  Programming,  Budgeting  and  Execution  process  is  implemented. 
Its  strength  is  the  consistency  of  reviews  through  successive  grade  levels  and  experience  within  the  functional  staff. 
It  provides  balance  in  resource  allocation  decisionmaking. 
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•  deliver  IT  in  manageable  increments,  considering  complexity,  operational  priorities  (e.g., 
auditability,  legacy  system  retirement),  implementation  of  basic  functionality  before 
extensions,  complete  end-to-end  processes  where  feasible,  and  coordination  with  related 
initiatives  (e.g.,  reorganization,  replacement  or  upgrades  of  legacy  systems,  changes  in 
hosting  environment) 

•  engage  experts  with  in-depth  knowledge  of  functional  operations  and  others  with  relevant 
technology  experience  to  guide  ERP  implementation. 
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1.  Introduction 


Background 

Over  the  years,  information  technology  (IT)  has  played  an  increasingly  significant  role  in  the 
way  organizations  conduct  business.  Initially,  IT  was  used  chiefly  to  achieve  operational 
efficiencies  by  automating  routine  tasks  of  existing  business  processes.  Subsequently,  IT  began 
to  be  used  to  enable  improved  management  planning  and  decisionmaking,  primarily  through  the 
collection,  analysis,  and  timely  dissemination  of  improved  data.  In  some  instances,  IT  has  even 
served  as  the  key  enabler  of  an  organization’s  strategic  goals.1  In  sum,  IT  has  evolved  from  a 
narrow  tool  for  automation  to  a  potential  enabler  of  business  transformation.2 

Enterprise  Resource  Planning  (ERP)  systems,  which  grew  out  of  manufacturing  resource 
planning  systems  in  the  1990s,  are  prime  examples  of  the  transformative  potential  of  IT.  ERP 
systems  are  configurable  commercial  off-the-shelf  (COTS)  software  packages  that  enable  an 
organization  to  integrate  operational  and  management  processes  across  a  broad  range  of  internal 
business  activities,  including  procurement,  accounting,  finance,  and  human  resources  (see  Figure 
1.1  for  a  comparison  of  traditional  IT  and  integrated  ERP  concepts).  ERPs  can  confer  a  range  of 
benefits  to  an  organization  that  are  strategic,  managerial,  operational,  organizational,  and 
technological  in  nature  (e.g.,  see  Davenport,  2000;  Eckartz,  2009;  Shang,  2002;  Staehr,  2010). 


Figure  1.1.  Traditional  Stovepiped  IT  vs.  Horizontally  Integrated  ERP  Concepts 


Traditional  Stovepiped  IT  Horizontally  Integrated  ERP 

Domain  1  Domain  2  Domain  3  Domain  lDomain  2  Domain  3 


Vertically  oriented  processes  with  Horizontally  integrated  processes  eliminate 
checkpoints  between  domains  checkpoints  and,  possibly,  specific  functions 

Source:  Adapted  from  Sommer,  2006,  pp.  125-126 


1  Examples  of  this  are  United  Parcel  Service,  which  invested  heavily  in  IT  in  the  1990s  to  achieve  strategic  goals 
and  in  doing  so  attained  leadership  in  its  industry,  as  well  as  Amazon  and  Dell,  whose  business  models  hinge  on  the 
use  of  IT  (Ward  and  Daniel,  2006). 

2 

~  Business  transformation  definitions  vary,  but  the  term  generally  refers  to  strategic,  enterprise-wide  change  that  has 
a  profound  impact  on  an  organization’s  capabilities,  environment,  and  performance  (e.g.,  see  Capgemini,  2012). 
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Regardless  of  the  reason  an  organization  pursues  an  ERP,  doing  so  generally  entails 
significant  business  change.  This  is  because  ERP  systems,  by  virtue  of  their  enterprise  scope, 
affect  a  large  number  of  organizational  departments  and  processes.  Thus,  ERP  systems  ought  to 
be  viewed  as  part  of  broader  business  change  initiatives  rather  than  as  simply  IT  projects.  Indeed, 
an  incomplete  appreciation  of  this  point  has  led  to  numerous  ERP  failures  in  both  the  private  and 
public  sectors. 

The  Department  of  Defense  (DoD)  and  the  military  services  have  implemented  or  are  in  the 
process  of  implementing  several  ERP  systems  to  enable  business  transformation  goals  and  meet 
the  fiscal  year  (FY)  2017  deadline  for  auditable  consolidated  financial  statements  (Public  Law 
99-433,  2010).  The  Air  Force  is  implementing  two  such  systems,  the  Air  Force  Integrated 
Personnel  and  Pay  System  (AF-IPPS)  and  the  Defense  Enterprise  Accounting  and  Management 
System  (DEAMS),  and  recently  canceled  a  third,  Expeditionary  Combat  Support  System 
(ECSS).3  These  ERPs  were  initiated  with  the  intent  of  improving  the  effectiveness  of  the  Air 
Force’s  business  functions  and  providing  operational  support  to  the  warfighter  (e.g.,  through 
improved  visibility  and  management  of  personnel  and  other  assets).  Importantly,  especially  in  an 
era  of  constrained  budgets,  these  ERPs  were  also  intended  to  reduce  the  cost  of  Air  Force 
business  functions,  which  compete  with  operations  and  modernization  for  funds. 

In  spite  of  the  importance  of  these  ERP  systems  to  DoD  business  operations,  the  costs  of 
ERP  acquisition  programs  are  growing,  their  schedules  are  slipping,  and  they  face  the  risk  of  not 
delivering  their  desired  business  benefits.  For  example,  a  recent  DoD  Inspector  General  (IG) 
report  assessed  six  of  these  ERP  systems  and  reported  schedule  delays  of  1.5-12.5  years  and  cost 
increases  totaling  $8.0  billion  (a  total  of  1 10  percent  cost  growth  over  original  baseline 
estimates)  (DoD  IG,  2012).  An  earlier  2010  Government  Accountability  Office  (GAO)  report 
examined  a  different  set  of  six  ERP  programs  and  reported  similar  cost  and  schedule  overruns,  as 
well  as  risks  of  not  realizing  intended  business  benefits  (GAO,  2010). 

These  difficulties  are  not  unique  to  the  Air  Force,  or  even  to  public-sector  organizations. 
Indeed,  the  past  two  decades  are  rife  with  spectacular  ERP  failures  in  both  the  private  and  public 
sectors.  The  importance  and  difficulty  of  ERP  system  implementation  has  prompted  a  vast  body 
of  literature  on  conditions  for  ERP  success,  which  we  summarize  in  the  next  section. 

Conditions  for  Success  and  Challenges 

The  notion  of  “success”  in  the  ERP  literature  is  the  realization  of  desired  business  benefits,4 
enabled  by  the  implementation  of  an  ERP  system,  within  budgeted  cost  and  schedule.  To  achieve 


3 

The  analysis  presented  in  this  report  was  completed  prior  to  the  Air  Force  termination  of  the  ECSS  program  on 
November  8,  2012  (Inside  the  Air  Force,  2012). 

4 

A  business  benefit  may  be  defined  as  an  advantage  gained  by  a  stakeholder,  or  group  of  stakeholders,  that  arises 
from  an  organization  carrying  out  new  activities,  improving  upon  the  activities  it  already  carries  out,  or  stopping 
activities  that  are  no  longer  required  (Ward  and  Daniel,  2006). 
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success,  several  often-cited  conditions  must  be  met,  including  the  following  (e.g.,  Finney  and 
Corbett,  2007): 

•  clear  objectives  and  a  solid  business  case  for  the  ERP  system  and  broader  business 
transformation5 

•  top  management  commitment  and  active  support  throughout  the  transformation  lifecycle 

•  effective  governance  structures  for  decisionmaking  throughout  the  transformation 
lifecycle 

•  alignment  of  the  organization’s  business  processes  and  those  in  the  ERP  software  through 
business  process  reengineering  (BPR)  rather  than  customization  of  the  software6 

•  effective  and  appropriate  organizational  change  management  (OCM)  techniques 
throughout  the  transformation  lifecycle7 

•  experienced  ERP  program  management 

•  appropriate  ERP  implementation  strategy  and  time  frame,  including  data  management. 

While  these  conditions  for  success  apply  to  private-  and  public-sector  organizations  alike, 
public-sector  organizations,  such  as  the  Air  Force,  face  heightened  challenges  in  achieving  them. 
Laws,  regulations,  and  policies  that  govern  who  can  perform  work  and  how  work  is  performed 
(combined  with  the  size  and  complexity  of  the  DoD)  constrain  the  organization’s  ability  to 
address  common  challenges,  such  as  cultural  resistance  to  change  and  obtaining  the  relevant  ERP 
experience  and  expertise.  In  addition,  DoD  organizations  are  challenged  by  a  cultural  tendency 
to  realize  an  operational  vision  through  the  acquisition  of  a  product,  as  well  as  frequent  turnover 
of  senior  leadership,  acquisition,  and  functional  staff.  The  number  of  stakeholders  in  the  DoD, 
each  potentially  having  a  unique  chain  of  command,  also  results  in  a  more  fragmented  and 
inefficient  leadership  and  governance  structure  than  is  typically  observed  in  a  private 
corporation.  These  challenges  have  led  to  the  observation  that  “implementing  an  ERP  solution  is 
the  largest,  most  complex  technology  effort  most  public-sector  organizations  will  ever  attempt” 
(KPMG,  2011). 

While  many  of  the  challenges  listed  above  may  manifest  during  program  execution,  the  seeds 
of  these  challenges  are  sown  well  before  program  execution  decisions  are  made.  A  201 1  DoD 
memorandum  pointed  to  the  root  causes  of  ERP  challenges  that  exist  at  program  inception  as 
being  “more  profound”  than  those  during  management  and  execution  (Bliss,  2011).  As  discussed 
in  the  next  section,  we  therefore  focus  on  these  early  planning  issues  in  this  report. 


5  The  initial  purpose  of  a  business  case  is  to  justify  a  project’s  required  investment;  however,  business  cases  are  also 
increasingly  recognized  as  a  planning  and  management  tool  to  ensure  that  the  business  benefits  sought  are  ultimately 
realized. 

6  BPR  is  defined  as  the  radical  redesign  of  business  processes  to  achieve  dramatic  improvement  in  business 
performance  (Hammer  and  Champy,  2003). 

7  OCM  is  a  term  used  to  describe  an  organization’s  efforts  to  garner  support  for  changes  and  encourage  their 
adoption. 
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Overview  of  Research 


Research  Objectives 

The  research  documented  in  this  report  had  two  complementary  objectives: 

•  to  outline  the  key  early  planning  issues  associated  with  ERP  programs  and  provide  the 
Air  Force  with  recommendations  on  how  it  can  improve  this  planning  in  the  future 

•  to  determine  how  these  issues  might  manifest  during  ERP  program  execution  and  provide 
recommendations  on  how  the  Air  Force  can  improve  its  early  assessments  of  ERP 
programs. 

By  “key  early  planning  issues”  we  mean  the  critical  issues  that  ought  to  be  considered  before 
and  shortly  after  an  acquisition  program  is  initiated.8  With  respect  to  the  Business  Capability 
Lifecycle  (BCL)  framework,9  this  point  in  time  is  the  end  of  the  Investment  Management  Phase, 
or  Milestone  A.  This  report  is  not  a  “lessons  learned”  case  study  analysis  of  troubled  programs, 
but  an  analysis  of  steps  the  Air  Force  should  take  to  improve  the  success  of  business 
transformation,  of  which  ERP  acquisition  can  be  a  part. 

The  focus  on  ERP  programs  is  not  meant  to  suggest  that  the  Air  Force  or  DoD  should  view 
ERP  systems  as  the  preferred  business  IT  solution  for  all  circumstances.  In  fact,  as  explained 
throughout  this  report,  ERP  systems  have  transformative  potential  but  are  accompanied  by  a 
range  of  conditions  for  success  that  can  be  challenging  to  achieve. 

Research  Approach  and  Framework 

To  achieve  our  research  objectives,  we  began  by  carrying  out  an  extensive  review  of  success 
factors,  lessons  learned,  and  best  practices  related  to  ERP  planning.  This  was  accomplished 
through  a  review  of  the  private-sector  ERP  literature,  as  well  as  the  relatively  limited  public- 
sector  literature,  and  through  discussions  with  experts  from  ERP  software  vendors,  system 
integrators,  academics,  and  consultants.  The  second  phase  of  our  research  involved  in-depth 
investigation  of  the  major  Air  Force  ERP  programs — AF-IPPS,  DEAMS,  and  ECSS.  We 
reviewed  program  documentation  available  to  us  through  Defense  Acquisition  Management 
Information  Retrieval  (DAMIR),  DoD  IT  Portfolio  Repository  (DITPR),  program  management 
offices  (PMOs),  functional  management  offices  (FMOs),10  and  our  research  sponsors.  In 
addition,  we  engaged  in  discussions  with  individuals  from  the  following  stakeholder 
communities: 


g 

An  in-depth  exploration  of  implementation  issues  occurring  after  program  initiation  was  outside  the  scope  of  this 
analysis. 

9 

This  framework  governs  IT  acquisitions  in  excess  of  $1  million  (Carter,  201 1). 

10  DAMIR  and  DITPR  are  DoD  acquisition  databases.  The  PMO  is  the  acquisition  office  executing  the  program  and 
the  FMO  is  the  office  representing  the  “user”  community  of  the  program. 
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•  Government:  functional  sponsor,  FMO,  PMO,  acquisition  leadership,  Service  and  Office 
of  the  Secretary  of  Defense  (OSD)  Deputy  Chief  Management  Officer  (DCMO)  staff, 
and  Service  Chief  Information  Officer  (CIO)  staff. 

•  Contractors:  system  integrators,  software  vendors,  and  ERP  expert  consultants. 

To  organize  the  planning  issues  considered  in  our  research,  we  employed  the  framework 
depicted  in  Figure  1 .2  for  business  transformation  associated  with  ERP  systems.  Business 
transformation  is  justified,  and  guided  at  a  high  level,  by  the  business  case.  Executing  the 
transformation  entails  decisions  across  a  range  of  activities  and  stakeholder  communities.  The 
criteria  for  such  decisions  are  derived  from  the  business  case.  A  transformation  brings  an 
organization  from  a  current  (or  AS-IS)  business  environment  to  a  target  (or  TO-BE)  one,  each 
including  business  processes,  the  organization,  and  IT.  Business  processes  codify  the  way 
business  is  done;  and  the  organization,  which  is  made  up  of  people,  culture,  and  organizational 
structure,  carries  out  these  processes  with  the  aid  of  IT  (e.g.,  an  ERP  system).  BPR,  OCM,  and 
IT  acquisition  directly  enable  the  transformation  of  the  AS-IS  environment  to  the  TO-BE 
environment.  This  framework  was  derived  through  a  review  of  how  ERP — and  IT,  more 
generally — delivers  business  value  to  organizations  and  the  ERP  success  factor  literature  (e.g., 
Davenport  2000;  Gulledge  and  Sommer  2003;  Finney  and  Corbett,  2007;  Nah  and  Delgado, 

2006;  Ward  and  Daniel,  2006). 


Figure  1.2.  Research  Framework  for  this  Analysis 


AS-IS  Environment 

•  Business  Processes 

•  Organization 


•  IT 


Justified  and  Guided  by: 

Business  Case 

- >• 


Enabled  by: 

Governance 

Business  Process  Reengineering  (BPR) 
Organizational  Change  Management  (OCM) 
IT  Acquisition 


TO-BE  Environment 

•  Business  Processes 

•  Organization 

•  IT 


As  suggested  above,  these  five  areas  are  deeply  interconnected.  The  remainder  of  this  report 
will  clarify  how  the  decisions  and  activities  carried  out  in  these  areas  infonn  each  other  and  must 
be  jointly  orchestrated  to  ensure  successful  transformation.  Moreover,  these  activities  should  be 
coordinated  over  time  across  different  organizational  echelons — enterprise,  functional,  and 
program — within  the  Air  Force. 


Overview  of  Report 

This  report  is  organized  in  accordance  with  the  research  framework  depicted  in  Figure  1.2.  The 
business  case,  which  is  the  keystone  document  justifying  and  guiding  the  business 
transformation,  is  addressed  in  Chapter  Two.  Chapter  Three  addresses  governance  issues,  which 
affect  the  effectiveness  with  which  decisionmaking  is  conducted  throughout  the  transformation. 
Chapters  Four,  Five,  and  Six  address  BPR,  OCM,  and  IT  acquisition,  respectively.  In  each  of 
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these  chapters,  conditions  for  success  and  Air  Force  challenges  to  meeting  these  conditions  are 
described.  Chapter  Seven  includes  a  summary  of  key  findings  and  recommendations  for 
improved  planning  organized  by  temporal  phase:  pretransformation;  transformation,  preprogram 
initiation;  and  post-program  initiation.  Appendix  A  outlines  a  suggested  planning  framework, 
which  expands  upon  Figure  1.2  and  encompasses  the  ideas  presented  in  the  report.  Implications 
for  ERP  program  assessment,  which  draw  upon  all  of  the  above,  appear  in  Appendix  B. 
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2.  Business  Case 


The  purpose  of  the  business  case  for  an  IT  project  has  traditionally  been  to  justify  the  investment 
required  for  the  project,  usually  in  financial  terms.  However,  as  the  role  of  IT  evolved  from 
automating  routine  tasks  of  existing  business  processes  to  enabling  fundamental  business 
change — such  as  improving  visibility  of  personnel  and  other  assets  in  the  case  of  Air  Force 
ERPs — the  role  of  the  business  case  has  expanded  too. 

The  initial  purpose  of  a  business  case  is  to  justify  a  project’s  required  investment.  However, 
this  justification  must  reflect  the  fact  that  projects  involving  IT — especially  multifunctional  IT, 
such  as  ERP  systems — are  part  of  broader  business  change  initiatives.  The  business  value  offered 
by  ERP  systems  often  spans  a  range  of  benefits,  many  of  which  may  not  be  easily  measured  in 
financial  terms  (e.g.,  reduced  cycle  time,  better  decision  support,  improved  workforce  skill  and 
morale).  Likewise,  the  costs  and  risks  associated  with  ERP-enabled  business  change  relate  to  a 
variety  of  activities  beyond  IT  acquisition  (e.g.,  BPR  and  OCM). 

Previously  used  to  justify  a  project’s  investment,  the  business  case  is  increasingly  being 
recognized  as  a  planning  and  management  tool  that  can  be  used  to  ensure  that  the  business 
benefits  sought  are  ultimately  realized  (Eckartz  et  al.,  2009;  Ward  and  Daniel,  2006).  The  need 
for  such  a  tool  stems  from  the  recognition  that  business  benefits  are  the  motivation  for  the  project 
and  from  the  observation  that  benefits  that  are  not  actively  managed  are  at  high  risk  of  not  being 
realized.  Non-Air  Force  DoD  ERP  experience  suggests  that  shortfalls  in  delivered  business 
capability  can  result,  even  if  programs  successfully  pass  through  acquisition  milestones. 

There  are  many  possible  formats  and  methodologies  for  assembling  a  business  case.1 
However,  in  all  instances,  an  enterprise  business  strategy  and  identification  of  business  goals  and 
derived  benefits  should  drive  the  analysis  underlying  the  business  case  because  this  is  the 
motivation  for  pursuing  IT-enabled  business  change.  Realizing  business  benefits  entails  a 
coordinated  set  of  activities,  as  suggested  by  Figure  1.2  in  Chapter  One,  and  these  activities  must 
therefore  be  considered  in  the  business  case,  both  when  justifying  the  project’s  investment  and 
when  planning  the  realization  of  benefits.  In  particular,  identifying  these  enabling  activities 
provides  the  basis  for  analyzing  the  full  range  of  IT  and  non-IT  costs,  schedule  drivers,  and 
sources  of  risk.  Finally,  justification  of  the  solution  for  meeting  the  stated  business  goals  often 
entails  a  comparison  to  alternatives.  The  basis  for  this  justification  should  be  an  assessment  of 
the  business  value  offered  by  each  alternative  relative  to  the  stated  enterprise  goals,  in  view  of 
the  associated  cost,  schedule,  and  risk. 

In  the  context  of  this  report,  an  Air  Force  enterprise  business  strategy  would  address,  at  a 
high-level,  how  business  operations  support  the  operational  priorities  of  the  Air  Force.  It 
describes  the  principles,  goals,  and  objectives  that  are  the  foundation  for  an  Air  Force  Business 


1  We  refer  the  interested  reader  to  Nafeeseh  and  Al-Mudimigh  (2011);  Gunasekaran,  Ngai,  and  McGaughey  (2006); 
Mercken  (2005);  and  Ward  and  Daniel  (2006)  and  references  therein  for  a  survey. 
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Enterprise  Architecture.  It  also  is  the  framework  for  cross-functional  decisionmaking  and  the 
adjudication  of  touchpoints  between  functionals.  Additionally  it  supports  other  higher-level 
strategies  as  required.  This  business  strategy  could  include,  but  not  be  limited  to,  the  following 
components: 

•  architecture  of  enterprise  business  operations  (e.g.,  service-oriented  architecture, 
Oracle-based  ERPs,  location  of  shared  functions,  data  standards  for  shared  data) 

•  enterprise  migration  timeline  (e.g.,  auditability  by  2017) 

•  enterprise  priorities  (e.g.,  total  asset  visibility,  reduction  of  personnel  costs, 
auditability). 

In  the  next  section,  we  highlight  the  critical  elements  required  to  build  a  rigorous  business 
case.  These  conditions  for  success  are  drawn  from  our  research  into  private-  and  public-sector 
ERP  experience;  links  to  recent  DoD  acquisition  policy  and  guidance  are  made  when 
appropriate.  Following  this,  we  describe  the  challenges  that  the  Air  Force  faces  in  meeting  these 
conditions  for  success.  Note  that  in  this  report,  we  refer  to  the  business  case  in  a  broader  sense 
than  defined  by  the  BCL  framework.  The  business  case  discussion  in  this  report  applies  to 
business  change  initiatives  regardless  of  whether  the  initiative  involves  IT  acquisition.  In 
contrast,  the  BCL  business  case  policy  and  guidance  is  only  applicable  when  an  IT  component 
will  be  procured  as  part  of  the  business  change  effort.i 2 

Conditions  for  Success 

Our  research  indicates  that  successful  ERP  business  cases  require  the  following  conditions: 

•  alignment  between  enterprise  business  goals  and  strategy 

•  detailed  definition  of  business  benefits 

•  linkage  of  benefits  to  enabling  activities 

•  comprehensive  analysis  of  alternatives. 

We  discuss  each  of  these  conditions  in  more  detail. 

Alignment  Between  Enterprise  Business  Goals  and  Strategy 

The  business  case  should  begin  with  identification  of  enterprise  business  goals  that  motivate  the 
business  change.  These  goals  should  be  a  high-level  response  to  business  drivers — internal  and 
external  pressures  for  change — acting  upon  the  organization.  For  public-sector  organizations 
such  as  the  Air  Force,  examples  of  such  drivers  could  be  unsustainable  costs  of  operating  and 
maintaining  aircraft  or  a  statutory  requirement  for  auditable  financial  statements. 

These  enterprise  business  goals  ought  to  be  consistent  with  a  broader  enterprise  strategy  that 
considers  the  full  range  of  drivers  acting  upon  it.  At  the  DoD  level,  the  National  Defense 
Strategy  produced  by  the  Secretary  of  Defense  (and  informed  by  the  President’s  National 


i 

“We  acknowledge  that  the  BCL  business  case  requires  that  the  full  spectrum  of  Doctrine,  Organization,  Training, 
Materiel,  Leadership  and  Education,  Personnel,  and  Facilities  (DOTMLPF)  considerations  be  addressed  before 
decisions  on  whether  IT  acquisition  is  necessary  to  fulfill  needs. 
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Security  Strategy)  is  the  overarching  enterprise  strategy,  and  the  Strategic  Management  Plan, 
which  supports  it,  is  the  DoD  strategy  document  for  business  operations.  This  DoD-level 
guidance  should  inform  analogous  strategies  for  DoD  organizations,  such  as  the  Air  Force.  The 
importance  of  setting  goals  aligned  with  enterprise  strategy  may  be  obvious,  but  making  this 
explicit  in  a  business  case  is  especially  critical  for  ERP-enabled  business  change,  because  it 
provides  guidance  for  governance  and  OCM  activities  involving  diverse  stakeholders  who  often 
have  conflicting  goals  and  priorities.  Moreover,  explicit  alignment  with  an  enterprise  strategy 
fosters  compatibility  and  avoids  duplication  with  other  business  change  initiatives  being  carried 
out  within  the  enterprise.  For  example,  to  achieve  a  goal  of  financial  auditability,  the  Air  Force 
may  conclude  that  it  is  more  expedient  and  cost-effective  to  increase  the  size  of  its  financial 
management  workforce  along  with  incremental  changes  to  business  processes  and  systems. 
Flowever,  if  the  Air  Force  is  pursuing  improved  asset  visibility  as  part  of  its  business  strategy,  it 
may  instead  decide  in  favor  of  ERP-enabled  business  change  that  cuts  across  multiple  functional 
domains  (e.g.,  financial  management,  logistics,  human  resources)  and  that  can  also  enable 
auditability.  However,  as  will  be  explained  throughout  this  report,  carrying  out  such  an 
expansive  initiative  involving  stakeholders  with  potentially  conflicting  priorities  requires  explicit 
alignment  of  goals  and  Air  Force  strategy. 

Recent  DoD  IT  acquisition  policy  and  guidance  (Carter,  2011;  DoD,  2012a)  is  consistent 
with  this  condition  for  success.  In  particular,  the  identification  of  business  goals  and  their 
alignment  with  strategy  are  required  in  the  “problem  statement”  portion  of  the  DoD  BCL 
business  case  that  is  submitted  prior  to  Materiel  Development  Decision  (MDD),  the  entry  point 
to  the  acquisition  system. 

Detailed  Definition  of  Business  Benefit 

After  defining  the  enterprise  business  goals,  articulating  how  specific  benefits  will  achieve  high- 
level  goals  is  the  next  critical  step.  A  business  benefit  may  be  defined  as  an  advantage  gained  by 
a  stakeholder,  or  group  of  stakeholders,  that  arises  from  an  organization  carrying  out  new 
activities,  improving  upon  the  activities  it  already  carries  out,  or  stopping  activities  that  are  no 
longer  required  (Ward  and  Daniel,  2006). 

Business  benefits  should,  to  the  extent  possible,  be  expressed  in  measurable  terms  in  the 
business  case — even  using  metrics  requiring  subjective  assessment  (e.g.,  for  workforce 
morale) — and  include  AS-IS  and  TO-BE  values  along  with  a  method  for  measurement  to  help 
track  their  realization.  While  metrics  that  can  be  expressed  in  financial  terms  are  attractive  in  that 
they  may  be  aggregated  into  an  economic  analysis  along  with  project  costs,  the  importance  of 
non-financial  benefits  for  IT  systems,  such  as  ERPs,  should  not  be  discounted  because  they,  too, 
can  provide  significant  business  value.  Note  that  providing  values  for  metrics  entails  an 
understanding  of  AS-IS  and  TO-BE  performance  and  cost,  which  may  require 
simulation/modeling  tools,  benchmarking,  or  pilot  implementations  if  the  underlying  benefit 
entails  a  new  activity  (Ward  and  Daniel,  2006).  Each  benefit  should  also  have  an  “owner”  who  is 
responsible  for  its  realization.  Ideally,  each  benefit  owner  is  an  individual — but  can  also  be  a 
small  group  of  individuals — receiving  the  benefit,  thus  guaranteeing  an  incentive  to  help  ensure 
that  the  benefit  is  realized.  Finally,  it  should  be  noted  that,  while  articulating  a  complete  set  of 
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benefits  is  ideal  when  building  the  business  case,  unplanned  business  benefits  frequently  arise 
after  the  IT  system  is  implemented  and  the  organization  better  understands  how  to  exploit  the  IT 
to  obtain  business  value.3 

Recent  DoD  IT  acquisition  policy  and  guidance  supports  this.  Detailed  definition  of  benefits 
and  the  need  for  a  “capability  delivery  plan”  are  articulated  as  key  portions  of  the  DoD  BCL 
business  case.  However,  the  capability  delivery  plan  is  a  high-level  acquisition-oriented  artifact 
that  does  not  necessarily  address  the  full  scope  of  benefit  management.4 

Linkage  of  Benefits  to  Enabling  Activities  and  Considerations 

A  critical  part  of  building  the  business  case  is  to  characterize  how  the  business  benefits  will  be 
delivered  through  transformation  of  AS-IS  to  TO-BE  business  processes,  organization,  and  IT 
(Eckartz  et  ah,  2009;  Ward  and  Daniel,  2006).  Recall  that  the  activities  and  considerations 
enabling  this  transformation  span  governance,  BPR,  OCM,  and  IT  acquisition.  Consideration  of 
these  activities  forms  the  basis  for  the  DOTMLPF  analyses  required  in  DoD  BCL  business  cases 
(Carter,  2011;  DoD,  2012a).  As  with  benefits,  promoting  accountability  through  ownership  (i.e., 
execution  and  funding)  of  these  activities  and  the  changes  they  are  intended  to  produce  is  critical. 
These  activities  and  their  conditions  for  success  are  discussed  in  subsequent  chapters  of  this 
report. 

Establishing  the  link  between  benefits  and  enabling  activities  is  critical  for  at  least  three 
reasons.  First,  such  linkage  provides  the  foundation  for  inclusive  cost,  schedule,  and  risk 
analyses  in  the  business  case  because  it  helps  ensure  that  all  relevant  activities  and  issues  are 
identified.  Second,  a  rough  cost,  schedule,  and  risk  assessment — that  is,  an  initial  rough  business 
case — often  leads  an  organization  to  refine,  delay,  or  even  abandon  the  goals  and  benefits  it 
wishes  to  pursue  if  the  perceived  cost,  schedule,  and  risk  are  too  great.  Finally,  the  link  between 
benefits  and  enabling  activities  provides  the  foundation  for  managing  the  process  to  realize  the 
benefit  throughout  the  project’s  lifecycle. 

In  developing  this  link,  DoD  acquisition  policy  requires  that  IT  acquisition  be  considered 
only  after  non-IT  enablers  have  been  considered  and  deemed  inadequate  to  meet  the  desired 
business  goals  (Carter,  2011).  This  policy  helps  retain  focus  on  achieving  business  benefit,  rather 
than  on  acquiring  IT  as  the  goal.  In  general,  different  TO-BE  solutions — each  comprising 
business  process,  organization,  and  IT  components — may  achieve  the  same  high-level  business 
goals.  However,  if  some  form  of  IT  acquisition  is  needed  in  all  cases,  this  analysis  must  be 
summarized  at  MDD  in  the  “problem  statement.” 

Comprehensive  Analysis  of  Alternatives 

As  noted  above,  the  process  of  building  the  business  case  will  often  reveal  that  alternative 
solutions  exist  for  achieving  the  high-level  business  goals.  Chapter  Six  addresses  the  range  of  IT 


3 

Issues  and  methodologies  on  identification  of  benefits  can  be  found  in  Eckartz  et  al.  (2009),  Love  et  al.  (2005), 
Mercken  (2005),  and  Ward  and  Daniel  (2006)  and  references  therein. 

4 

See  Ward  and  Daniel  (2006)  for  a  comprehensive  treatment  of  benefit  management. 


-  10- 


components  of  these  solutions  that  should  be  considered.  Once  the  range  of  alternatives  has  been 
established,  the  basis  for  selecting  the  preferred  alternative  should  be  an  assessment  of  the 
business  value  offered  by  each,  in  view  of  the  associated  cost,  schedule,  and  risk.  Note  that 
selection  of  the  preferred  alternative  generally  involves  some  subjectivity  because  it  involves  a 
comparison  of  more  than  just  an  economic  analysis  of  costs  and  financial  benefits;  it  also  entails 
a  comparison  of  nonfinancial  benefits  (e.g.,  a  modular  or  evolutionary  migration  path)  and  risks 
that  can  be  dissimilar  in  kind.  Nevertheless,  capturing  the  full  range  of  benefits,  costs,  risks,  and 
schedules  builds  the  foundation  for  making  an  informed  and  defensible  alternative  selection. 

If  the  alternative  solutions  involve  an  IT  component,  the  venue  for  assessing  alternatives  is 
the  Analysis  of  Alternatives  (AoA),  just  after  MDD.  To  comply  with  DoD  IT  acquisition  policy, 
the  problem  statement  and  results  of  the  AoA  are  part  of  the  DoD  BCL  business  case  that  must 
be  submitted  before  program  initiation  (i.e.,  Milestone  A).5  The  timing  of  the  business  case 
submission  ensures  that  a  sound  justification  for  the  IT-enabled  initiative  exists  before 
committing  substantial  funds.  However,  as  noted  above,  this  relies  on  a  good  understanding  of 
the  AS-IS  environment  and  supporting  analyses  of  enabling  activities.  That  said,  the  business 
case  is  a  living  document  refined  over  time  as  subsequent  activities  shed  further  light  on  benefits 
and  associated  changes  (Davenport,  2000;  Eckartz  et  ah,  2009;  Ward  and  Daniel,  2006). 

Challenges 

Air  Force  ERPs  have  been  motivated  by  business  transformation  goals.  However,  discussions 
with  Air  Force  functional  stakeholders  and  a  2008  GAO  report  indicate  that  the  transformational 
goals  underlying  ECSS  and  DEAMS  were  not  coordinated  with  an  overarching  Air  Force  or 
DoD  enterprise  business  strategy. 

Moreover,  the  translation  of  these  transformation  goals  into  specific  benefits  before  program 
initiation  has  been  lacking.  Shortcomings  in  early  benefit  definition  have  included  the  absence  of 
metrics;  metrics  that  cannot  be  tracked;  missing  AS-IS  values  for  metrics;  missing  or  unrealistic 
TO-BE  values  for  metrics;  and  the  absence  of  any  benefit  description  at  all.  As  explained  in  the 
previous  section,  a  poor  definition  of  benefits  undermines  an  assessment  of  the  potential  business 
value  of  the  ERP-enabled  initiative  and  significantly  imperils  the  realization  of  its  business 
benefits. 

There  are  several  reasons  for  bad  benefit  definition.  These  include,  for  example,  a  poor 
understanding  of  the  AS-IS  business  environment  (i.e.,  processes,  costs,  performance),  which 
precludes  establishing  a  baseline.  The  absence  of  enabling  activities  to  establish  the  link  between 
benefits  and  required  business  process,  organizational,  and  IT  changes  could  result  in  missing  or 
unrealistic  TO-BE  metric  values.6  Finally,  disincentives  have  been  cited  as  reasons  for  omitting 


5  DoD  IT  acquisition  policy  also  requires  that  summaries  of  other  documents  and  analyses  be  included  in  the 
business  case.  See  Carter  (201 1)  for  further  details. 

6  The  best  metrics  typically  measure  business  results  rather  than  the  performance  of  intermediate  processes. 
Examples  might  include  time  to  complete  end-to-end  processes,  error  rate,  inventory  reduction,  processing 
efficiency,  savings  from  retiring  legacy  systems,  or  the  accuracy  or  utility  of  available  management  information. 


-  11  - 


descriptions  of  manpower  and  monetary  efficiencies  or  other  benefits.  These  benefits  are  often 
conferred  broadly  on  the  Air  Force  or  DoD  enterprise  as  a  whole,  so  individual  stakeholders  may 
not  benefit  directly  and  may  even  be  worse  off  if  their  manpower  or  funding  is  reduced  before 
the  overall  efficiency  is  realized. 

Related  to  the  lack  of  benefit  definition  is  the  failure  to  establish  the  link  between  benefits 
and  enabling  activities  before  initiating  the  ERP  program.  As  discussed  in  the  previous  section, 
the  absence  of  this  link  impairs  a  full  consideration  of  cost,  schedule,  and  risk,  which  can  in  turn 
undermine  the  assessment  of  solution  alternatives.  In  terms  of  non-IT  considerations,  the  impact 
of  BPR,  governance,  and  OCM  all  appear  to  have  been  underappreciated.  BPR  itself  is  an 
intensive  activity  that  directly  influences  cost  and  schedule.  Moreover,  the  rigor  with  which  BPR 
is  conducted  affects  the  risk  of  realizing  benefits  as  well  as  cost  and  schedule.  Additionally,  the 
absence  of  critical  OCM  activities  and  effective  governance  could  delay  decisionmaking  (leading 
to  schedule  delay  and  cost  growth),  and  could  also  result  in  compromises  on  requirements  that 
might  lead  to  diminished  realized  business  benefits  or  even  program  cancellation.  With  respect  to 
IT  enablers,  data  management  and  compatibility  with  IT  infrastructure — which  are  significant 
drivers  of  cost  and  schedule,  and  sources  of  risk — also  appear  to  have  been  underappreciated. 

Recent  DoD  IT  policy  and  guidance  have  been  positive  steps  toward  mitigating  these 
challenges,  as  they  are  consistent  with  the  conditions  for  success  noted  throughout  this  chapter. 
To  be  a  truly  useful  artifact  for  ERP-enabled  business  transformation,  however,  the  business  case 
must  be  carried  out — and  enforced — with  the  completeness  and  rigor  intended  by  this  policy  and 
guidance. 

Summary 

The  business  case  is  the  keystone  document  of  a  business  transformation  initiative.  Its  dual 
purposes  are  to  justify  the  initiative  and  help  plan  and  manage  the  realization  of  its  benefits. 
While  there  are  many  possible  formats  and  methodologies  for  assembling  a  business  case,  the 
enterprise  business  goals  and  derived  benefits  being  pursued  should  drive  its  formulation. 
Benefits  should  be  defined  and  quantified  to  the  extent  possible.  Moreover,  it  is  essential  to 
explicitly  tie  these  benefits  to  the  enabling  business  process,  organizational,  and  IT  changes  for 
the  solutions  being  considered.  It  helps  refine  the  scope  of  the  solution  alternatives  and  it 
provides  the  foundation  for  cost,  schedule,  and  risk  analysis,  as  well  as  the  basis  for  comparing 
the  alternatives. 

The  Air  Force,  however,  struggles  in  meeting  these  conditions  for  success.  A  major  reason  is 
that  it  has  a  poor  understanding  of  the  AS-IS  business  environment,  which  in  turn  impairs  its 
ability  to  carry  out  the  analyses  and  activities  that  aid  in  building  a  solid  business  case.  The  next 
four  chapters  elaborate  on  conditions  for  success  and  challenges  with  respect  to  these  supporting 
activities  and  analyses,  and  Chapter  Seven  provides  recommendations  to  help  the  Air  Force 
overcome  barriers  to  success. 
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3.  Governance 


Governance  should  support  focused  decisionmaking  using  criteria  based  on  the  business  case  to 
achieve  the  organization’s  overall  goals.  Because  these  decisions  affect  all  levels  and  areas  of  the 
transformation,  governance  needs  to  be  consistent  across  echelons  (from  the  enterprise  to  the 
specific  program  level);  align  stovepipes;  and  be  applied  across  BPR,  OCM,  and  IT  acquisition. 

Decisionmaking  criteria  are  a  direct  output  of  the  business  case.  These  criteria  establish  a 
foundation  for  resolving  issues  in  a  timely  and  effective  manner — regardless  of  the  governance 
structure  selected  (multi-echelon  or  multifunctional).1  Value-added  governance  must  be  timely 
and  effective  enough  to  support  the  success  of  the  transformation. 

The  decisionmaking  processes,  and  therefore  the  governance  structures,  differ  between 
industry  and  government;  however,  the  conditions  for  success  are  similar.  Differences  include 
decisionmaking  approaches;  constraints  such  as  laws,  regulations,  and  policies;  budgeting 
processes;  and  oversight  levels. 

Conditions  for  Success 

Regardless  of  whether  it  is  to  be  applied  to  successfully  achieving  an  enterprise  transformation  or 
executing  a  specific  program,  effective  governance  should  be  based  on  decision  criteria 
understood  by  all  stakeholders.2  Ideally,  these  criteria  should  be  grounded  in  the  facts  of  the 
business  case  and  used  to  reinforce  achieving  the  defined  and  agreed-upon  goals  and  objectives. 
Basing  them  on  the  business  case — which  is  most  likely  established  early  in  the  activity  when  all 
the  participants  are  focused  on  broader  enterprise-level  perspectives  and  less  likely  to  be  focused 
on  self-interest — drives  objectivity  and  transparency  (Strachan,  2008). 

A  well-devised  governance  structure  should  be  simple  and  responsive,  and  it  should  guide 
transformational  activities  toward  achieving  the  organization’s  business  objectives.  It  fosters 
rational  decisionmaking  and  timely  direction,  continually  moving  the  transformation  forward. 

Ideally,  governance  should  provide  well-defined  roles  and  responsibilities,  and  clear 
boundaries.  It  is  preferable  that  governance  be  led  by  a  single  decisionmaker  who  is  reputable, 
knowledgeable,  and  fair.  If  a  decisionmaking  committee  is  unavoidable,  then  smaller  is  better,  as 
is  maintaining  transparent  and  well-understood  processes.  A  clear  decisionmaking  authority 
moves  project  teams  forward;  reduces  revisiting  decisions;  and  minimizes  project  delays,  costs, 
and  team  frustration  (KPMG  LLP,  201 1). 


1  Multi-echelon  means  one  person  is  in  charge  and  has  responsibility  for  implementation  decisions.  This  centralized 
approach  is  also  achievable  through  a  small  group  of  top-level  executives  because  one  person  rarely  has  all  the 
required  information.  Multifunctional  refers  to  a  body  of  members  with  experience  and  knowledge  across  a  broad 
scope  of  areas. 

2 

Stakeholders  should  be  identified  and  levels  of  influence  assessed  as  part  of  an  OCM  stakeholder  analysis. 
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Thus,  effective  governance  for  Air  Force  enterprise  business  activities  should  be  visibly 
supported  by  the  Air  Force’s  top  senior  leaders — SECAF,  CSAF,  the  Under  Secretary  of  the  Air 
Force  (USECAF),  and  VCSAF. 3  This  group  needs  to  ensure  on  a  regular  basis  that  the 
decisionmakers  are  advancing  their  activity  in  alignment  with  the  Air  Force  enterprise  vision — 
more  frequently  if  problems  develop.4 

Challenges 

Lack  of  Guidance  from  Business  Case 

As  described  in  Chapter  Two,  an  Air  Force-wide  enterprise  business  strategy  should  be  the 
foundation  for  the  business  case.  Flowever,  it  appears  the  business  cases  for  many  Air  Force 
transformations  are  more  narrowly  focused  on  functional  lines  instead  of  a  widely  acknowledged 
and  universal  Air  Force  enterprise  strategy.  These  business  cases  also  appear  to  be  documented 
after  the  fact,  sometimes  even  following  a  decision  to  pursue  an  IT  solution,  which  is  a  decision 
that  should  be  made  only  after  a  full  business  case  review.  In  these  circumstances,  the  foundation 
for  decisionmaking  criteria,  definition  of  roles  and  responsibilities,  and  transparency  are  all 
unfocused — making  it  difficult  to  integrate  governance  across  business  functions. 

Stovepiped  Organizational  Structure 

Another  complicating  factor  to  effective  governance  is  organizational  structure.  Privately  and 
publicly  held  companies  usually  have  a  multi-echelon  structure  with  a  chief  executive  officer  as 
the  ultimate  decisionmaker  and  integrator.  Functional  leaders/corporate  officers  (e.g.,  the  chief 
financial  officer,  chief  operating  officer,  chief  technology  officer,  CIO,  etc.)  report  to  the  chief 
executive  officer,  who  in  this  multi-echelon  structure  typically  has  the  final  say  on  enterprise 
decisions  (e.g.,  choosing  to  implement  an  ERP)  as  well  as  the  tools  to  drive  it  to  success,5  and 
will  be  there  long  enough  to  see  it  through.6 

In  the  DoD  and  Air  Force,  business  decisionmaking  is  typically  carried  out  by 
multifunctional  committees  working  together  to  achieve  consensus.  This  decision  model  has 
been  shown  to  be  less  effective  in  timely  decisionmaking,  providing  unambiguous  guidance, 


3 

As  the  Air  Force’s  chief  management  officer,  the  USECAF  is  responsible  for  "effectively  and  efficiently” 
managing  “Air  Force  business  operations”  (Under  Secretary  of  the  Air  Force,  2012). 

4 

The  Air  Force  has  taken  steps  in  providing  this  alignment  (Under  Secretary  of  the  Air  Force,  2012). 

5  Within  the  private  sector,  the  leadership  has  the  ability  to  offer  incentive  packages  to  encourage  individuals  to 
either  support  an  initiative  or  seek  employment  elsewhere.  This  is  not  as  easily  accomplished  within  the  public 
sector. 

6  Senior  leaders  transitioning  approximately  every  four  years  (military  rotations  and  political  appointees’  transience) 
inject  instability.  For  instance,  an  outgoing  official  might  delay  a  critical  decision  so  that  it  can  be  made  by  the 
incoming  individual,  who  will  live  with  the  outcome.  Conversely,  an  outgoing  official’s  decision  could  be  studied, 
delaying  implementation,  or  reversed  by  the  incoming  official  who  may  have  differing  priorities  or  views.  These 
situations  provide  opportunities  for  revisitation,  confusion,  and  discord;  nothing  is  ever  perceived  as  “closed.” 
Regardless,  decisionmaking  is  delayed,  additional  risk  is  introduced,  and  costs  and  schedules  increase. 
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controlling  special  interests,  or  being  supported  by  midlevel  managers  (Sommer,  2011). 
However,  this  is  the  default  governance  structure  within  any  Air  Force  transformation  because 
multiple  functional  stakeholders  are  involved.  They  reside  at  multiple  echelons,  from  the  Air 
Force  enterprise  to  a  specific  program  focused  on  a  single  outcome. 

Contributing  to  governance  difficulties,  the  Air  Force  has  divided  itself  organizationally  into 
two  parts  loosely  described  as  “business”  and  “operations/command.”7  As  seen  in  Figure  3.1, 
business  organizations  (in  red)  report  to  the  SECAF  and  operations/command  (in  blue)  to  the 
CSAF.  This  bifurcation  affects  governance  during  the  Air  Force’s  Planning,  Programming, 
Budgeting,  and  Execution  (PPBE)  process  and  during  preparation  of  the  service’s  budget.  The 
command  side  expects  the  business  infrastructure  to  support  operations,  but  business 
infrastructure  often  receives  lower  priority  during  the  budgeting  process.8  Air  Force  functional 
stovepipes  may  have  advocates  on  either  the  business  or  operations/command  sides  of  the  Air 
Force,  or  both. 


7 

The  “business”  side  of  the  Air  Force  has  civilian  leadership,  with  the  exception  of  Information  Dominance  and 
CIO,  and  includes  Financial  Management  and  Comptroller  (FM),  Manpower  and  Reserve  Affairs  (MR),  Acquisition 
(AQ),  Installations,  Environment  and  Logistics  (IE),  Space  (SP),  and  International  Affairs  (IA).  The 
“operations/command”  organizations  have  military  leadership  and  include  Manpower,  Personnel,  and  Services  (Al), 
ISR  (A2),  Operations,  Plans  and  Requirements  (A3/5),  Logistics,  Installations,  and  Mission  Support  (A4/7), 

Strategic  Plans  &  Programs  (A8),  Studies  &  Analysis,  Assessments,  and  Lessons  Learned  (A9),  Strategic 
Deterrence  and  Nuclear  Integration  (A10),  Reserve  and  National  Guard,  and  the  Surgeon  General.  There  are  teams 
where  a  civilian-run  organization  partners  with  a  military-run  one  within  the  same  functional  area,  e.g.,  MR  and  Al 
or  FM  and  A8.  Administrative  Staff  (AA)  and  Assistant  Vice  Chief  of  Staff  of  the  Air  Force  (CVA)  support  the 
offices  of  the  SECAF  and  CSAF. 

g 

During  the  PPBE  process,  various  leaders  advocate  funding  to  address  needs.  Historically,  day-to-day  operations 
are  prioritized  over  BPR,  and  OCM  and  recapitalization  of  weapon  systems  are  prioritized  over  defense  business 
systems  (DBS). 
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Figure  3.1 .  Headquarters  Department  of  the  Air  Force  Organization  Chart 


—  Secretariat 
Air  Staff 

-  Information  and  Coordination 


Source:  Adapted  from  U.S.  Air  Force,  2011a. 

Many  stakeholders,  who  may  be  leaders  of  functional  stovepipes,  are  affected  by  enterprise 
transformations  and  naturally  want  to  protect  their  interests.  This  desire  to  protect  a  specific 
interest  could  lead  to  optimizing  a  function  at  the  expense  of  the  enterprise.  A  functional 
transformation  will  have  touchpoints  with  other  functional  areas  (e.g.,  sharing  financials  between 
ECSS  and  DEAMS).  Specific  interests — frequently  using  laws,  regulations,  and  policies  as 
justification — have  contributed  to  separate  governance  structures  with  multiple  stovepipes  and 
layers  between  the  person  with  the  problem  and  the  ultimate  decisionmaker(s).  An  example  of 
this  can  be  seen  in  Figure  3.2.  While  there  are  some  horizontal  connections,  there  are  multiple 
management  structures  with  three  ‘top’  decisionmaking  bodies.  Acquisition  is  headed  by  the 
Under  Secretary  of  Defense  for  Acquisition,  Technology  and  Logistics  (USD  [AT&L])  and 
financial  management  by  the  Deputy  Assistant  Secretary  for  Financial  Operations  (SAF/FMP). 
Further  complicating  this  structure  is  the  Enterprise  Steering  Group,  whose  most  senior  member 
is  the  commander  of  the  U.S.  Transportation  Command  (USTRANSCOM/CC),  a  combatant 
commander.  The  relative  ranking  among  these  three  top  decisionmaking  bodies,  both  official  and 
unofficial,  is  unclear.  Furthermore,  within  these  silos  there  are  multiple  stakeholders  and  several 
layers  within  OSD  and  the  services.  A  consequence  of  a  multilayered,  cross-functional 
governance  structure  is  that  information  can  be  filtered,  diluted,  or  otherwise  changed.  This 
potentially  delays  critical  decisions  or  even  results  in  the  wrong  problem  being  addressed. 
Regardless,  either  case  could  adversely  impact  cost,  schedule,  and  benefits  realization. 
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Figure  3.2.  Example  of  an  Air  Force  ERP  Governance  Structure 


AFPEO=Air  Force  Program  Executive  Officer;  BES=Business  and  Enterprise  Systems;  CIRB=Combined  Investment 
Review  Board;  DFAS=Defense  Finance  and  Accounting  Service;  MDA=Milestone  Decision  Authority;  SAE=Service 
Acquisition  Executive. 

Source:  Adapted  from  U.S.  Air  Force,  March  22,  2012. 

External  stakeholders  are  an  additional  complication.  As  illustrated  in  Figure  3.2,  DFAS  and 
USTRANSCOM  are  both  outside  the  Air  Force,  yet  can  heavily  influence  planning  and 
decisionmaking.  Additionally,  any  Air  Force  system  needs  to  interact  within  the  DoD 
environment  and  will  be  subject  to  OSD-promulgated  policies  and  procedures,  as  well  as 
congressional  mandates.  This  can  increase  governance  complexity  with  multiple  layers  of 
oversight. 

Multiple  Layers  of  Oversight 

Public-sector  governance  also  has  additional  oversight  dictated  by  law  with  mandatory 
compliance  or,  in  the  case  of  regulations  and  policies,  requirements  to  request  waivers.  Failing  to 
address  these  initially  could  delay  program  execution,  and  could  result  in  larger  costs  and 
schedule  delays.  Some  significant  laws,  regulations,  and  policies  include:  the  Clinger-Cohen  Act 
(Public  Faw  104-106,  1996);  10  USC  Section — Defense  Information  Assurance  Program  (U.S. 
Code,  2006);  U.S.  Office  of  Management  and  Budget  (OMB)  Circular  A-130,  “Management  of 
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Federal  Information  Resources”  (OMB,  2012);  BCL  (Carter,  2011);  and  the  Defense  Acquisition 
System  directives  and  instructions  (DoD,  2000;  DoD,  2008). 9 

It  would  be  simpler  to  contend  with  so  many  laws,  regulations,  and  policies  if  they  were 
consistent,  but  this  is  not  always  the  case.  One  example  of  conflicting  laws,  regulations,  and 
policies  is  an  OMB  CIO  policy  letter  making  agency  CIOs  responsible  for  improving  management 
of  large  federal  IT  projects  by  identifying,  recruiting,  and  hiring  top  IT  program  management 
talent.  CIOs  are  directed  to  train  and  provide  annual  perfonnance  reviews  for  those  leading  major 
IT  programs.  Agency  CIOs  are  to  be  held  accountable  for  lowering  operational  costs,  terminating 
or  turning  around  troubled  projects,  and  delivering  meaningful  functionality  at  a  faster  rate  while 
enhancing  the  security  of  infonnation  systems  (Lew,  2011).  This  appears  to  conflict  with  the 
Defense  Acquisition  System  implemented  in  accordance  with  the  provisions  of  Goldwater-Nichols 
and  the  services’  Title  10  responsibilities  to  organize,  train,  and  equip  PMOs.10  So,  the  OMB  CIO 
policy  letter  and  statutes  identify  different  people  to  do  the  same  activities. 

Defense  business  systems  (DBS)  are  already  funded  through  the  PPBE  but  have  an  additional 
layer  of  oversight  through  the  BCL  framework.  This  framework,  established  by  the  USD(AT&L) 
for  DBS,  is  applicable  to  any  DBS  with  at  least  $1,000,000  across  all  appropriations.  The  BCL 
includes  an  annual  funds  certification  requirement  prior  to  the  program  expending  any  funds 
(Carter,  201 1).  The  BCL  requires  DBS  funds,  already  appropriated  and  authorized  through 
Congress,  to  be  certified  by  the  DBS  Management  Committee  through  its  Investment  Review 
Boards,  before  service  execution.  Within  the  services,  this  process  is  managed  in  the  CIO  or 
chief  management  officer  (CMO)  chains  and  is  outside  the  traditional  funding  and  acquisition 
communities.  This  increases  program  execution  complexity  as  the  program  manager  also  needs 
to  allow  for  the  BCL  certification  process  in  order  to  keep  to  a  schedule  and  maintain  timely 
benefits  realization. 


Summary 

Governance  is  decisionmaking  to  advance  an  organization’s  goals  and  objectives.  For  business 
transformations,  governance  should  be  based  on  and  support  the  business  case;  it  should  be 
simple,  flexible,  and  responsive;  and  ideally  it  should  have  a  single  reputable,  knowledgeable 
decisionmaker  at  the  top.  The  Air  Force  faces  several  challenges  in  accomplishing  these 
conditions  for  effective  governance.  These  include  untimely  or  pro  forma  business  cases  not 
aligned  with  an  Air  Force  vision  or  other  functional  visions,  a  bifurcated  organizational  structure 
with  a  multitude  of  influential  stakeholders  operating  within  functional  stovepipes,  and 
overlapping  and  conflicting  laws,  regulations,  and  policies. 


g 

Others  include  DoDD  8000.01,  Management  of  the  Department  of  Defense  Information  Enterprise  (DoD,  2009); 
Goldwater-Nichols,  Department  of  Defense  Reorganization  Act  of  1986  (Public  Law  99-433);  and  the  annual 
National  Defense  Authorization  Act. 

10  Goldwater-Nichols  outlined  the  position  of  the  Under  Secretary  of  Defense  for  Acquisition  and  established  the 
requirement  for  service  acquisition  executives  to  exclusively  manage  service  acquisition  functions.  When  the 
conflict  was  discussed  with  one  of  the  services’  leaders,  we  learned  that  he  simply  chose  to  interpret  the  policy  so  it 
did  not  conflict  with  Goldwater-Nichols  or  Title  10. 
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4.  Business  Process  Reengineering 


BPR  is  defined  as  the  radical  redesign  of  business  processes  to  achieve  dramatic  improvement  in 
business  performance  (Hammer  and  Champy,  2003).  BPR  is  typically  pursued  to  improve 
processes,  increase  productivity,  reduce  costs,  improve  customer  service,  and  provide  a 
competitive  advantage.  Continuous  process  improvement  (CPI)  is  similar  to  BPR  in  that  the 
objective  is  to  reduce  cost,  improve  productivity,  or  improve  some  other  aspect  of  business 
operations.  Both  are  important  activities  that  the  Air  Force  should  pursue.  However,  CPI  is 
generally  associated  with  marginal  changes,  rather  than  the  radical  transformations  sought  in 
BPR. 

Achieving  the  goals  and  objectives  of  BPR  often  requires  business  transformation  enabled  by 
IT.  The  implementation  of  IT  is  not  the  objective  of  the  BPR  activity,  however;  conducting  BPR 
before  identifying  an  IT  solution  is  considered  a  condition  for  ERP  success  (Esteves,  Pastor,  and 
Casanovas,  2002). 

Conditions  for  Success 

For  BPR  to  succeed,  a  number  of  common  challenges  must  be  overcome,  including  garnering 
senior  leadership  support,  performing  OCM,1  articulating  processes,  and  dealing  with  multiple 
cultural  and  environmental  contexts.  The  most  critical  challenge  to  overall  project  success  is  not 
technical;  rather,  it  involves  the  human  and  behavioral  aspects  of  OCM  (Somers  and  Nelson, 
2001).  It  naturally  follows  that  the  conditions  for  BPR  success  most  cited  in  the  literature  focus 
almost  entirely  on  mitigating  resistance  to  change.  We  discuss  the  most  commonly  cited 
conditions  for  success. 

Leadership  Support 

Effective  BPR  and  the  process  of  change  begins  with  top  management  support  and 
communication  of  the  vision,  goals,  motivation,  and  importance  of  the  BPR  project,  which  are 
encapsulated  into  the  developing  business  case,  to  the  stakeholders.  Once  the  goals  and  vision 
have  been  established,  empowered  decisionmakers  who  can  make  binding  calls  on  their 
communities  must  be  identified.  These  individuals  will  be  responsible  for  the  day-to-day 
decisions  required  to  carry  out  the  BPR  effort  and  achieve  the  identified  goals.  Senior  leadership, 
middle  management,  and  support  staff  must  have  sufficient  knowledge  of  BPR  to  establish 
realistic  goals  and  objectives  for  the  BPR  activities.  Realistic  expectations  include  the  timeframe 
for  BPR  activity  (Stoica,  Chawat,  and  Shin,  2003). 2  Those  involved  should  know  what  BPR  is, 
how  it  can  be  used,  and  what  can  be  achieved  through  BPR  activities.  If  necessary,  investment  in 


See  Chapter  Five  for  a  definition  and  discussion  of  OCM. 

2 

According  to  M.  Stoica,  N.  Chawat,  and  N.  Shin  (2003),  a  typical  BPR  project  can  last  between  one  and  two  years. 
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BPR  training  and  resources,  which  may  include  consultants,  may  be  pursued.  However,  the 
agency  should  have  adequate  resident  expertise  to  oversee  and  manage  contractor  BPR  activities 
(U.S.  General  Accounting  Office,  1997). 

Organizational  and  Incentives  Structure  Supporting  Cooperation  and  Communication 

It  is  critical  that  the  organizational  and  incentives  structure  support  a  cooperative  environment 
that  fosters  communication,  confidence,  and  trust  (Abdolvand,  Albadvi,  and  Ferdowsi,  2008)7 
One  of  the  key  activities  in  BPR  is  establishing  a  common  understanding  of  the  way  that  work  is 
currently  being  performed  across  the  organization.  We  refer  to  this  activity  as  the  documentation 
of  the  AS-IS  processes.  This  activity  would  detail  the  responsible  entities,  information  flows,  and 
activities  performed  for  each  process.  Another  key  activity  is  the  identification  and  development 
of  areas  where  process  could  be  improved,  to  produce  a  vision  of  the  desired  TO-BE  process. 
Documenting  the  AS-IS  and  developing  the  TO-BE  processes  involves  individuals  sharing 
information  that  could  suboptimize  a  local  process  for  the  betterment  of  the  enterprise.  For 
example,  if  two  functional  areas  were  individually  implementing  separate  accounting  processes 
to  optimize  their  individual  areas,  it  could  make  the  enterprise  less  efficient  due  to  additional 
steps  to  reconcile  financial  information.  If  the  accounting  process  were  shared  by  the  functionals, 
they  might  become  less  efficient  while  the  enterprise  improves  its  overall  efficiency  and 
transparency.  Both  these  key  activities  require  a  significant  level  of  trust  and  communication,  as 
well  as  a  belief  that  achieving  the  long-term  goals  and  objectives  of  the  transformation  are  more 
beneficial  than  the  short-term  costs. 

Minimize  Unnecessary  Customization 

Once  a  decision  is  made  to  pursue  a  materiel  solution,  a  fit-gap  assessment  is  performed  to 
identify  how  well  IT  implements  desired  processes.  When  a  gap  is  identified,  either  the  software 
can  be  customized  or  the  organization  may  decide  to  change  its  processes.  It  is  considered  best 
practice  to  adapt  business  processes,  rather  than  customize  the  software,  in  cases  where  the 
processes  incorporated  in  the  software  support  the  enterprise  objectives.  This  is  because 
customizing  the  software  can  minimize  the  intended  benefits  of  the  COTS  product,  and  has  an 
associated  cost. 

Challenges 

The  Air  Force  faces  a  number  of  challenges  to  achieving  these  important  conditions  for  BPR 
success.  The  challenges  associated  with  mitigating  resistance  to  change,  one  of  the  most 
important  conditions  for  BPR  success,  are  discussed  in  Chapter  Five.  The  challenges  associated 
with  establishing  a  governance  body  that  is  critical  to  driving  BPR  activities  are  discussed  in 


3 

See  Abdolvand,  Albadvi  and  Ferdowsi  (2008)  for  a  comprehensive  assessment  of  organizational  readiness  to 
perform  BPR. 
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Chapter  Three.  Other  challenges  associated  with  achieving  conditions  for  BPR  success  are 
described  here. 

Discussions  with  program  managers  and  Air  Force  ERP  stakeholders  have  confirmed  the 
findings  of  a  201 1  GAO  report  that  asserted  the  Air  Force  has  suffered  from  an  “immature  Air 
Force  (Business  Enterprise  Architecture  [BEA])  and  strategy”  (GAO,  20 1  I  ).4 5‘  This  has  hindered 
evolution  and  convergence  of  financial,  logistics,  and  human  resources  systems  and  processes 
and  has  resulted  in  program  decisions  that  require  changes  to  other  ERP  systems.  These  changes 
affect  program  schedules  and  cost. 

An  additional  challenge  is  a  lack  of  understanding  of  business  processes  at  the  enterprise  and 
program  levels.  The  organizational  structure  of  the  DoD  and  Air  Force  produces  individuals  with 
knowledge  of  how  work  is  accomplished  within  a  specific  area,  but  who  often  lack  an 
understanding  of  how  their  part  of  the  process  fits  into  a  larger  process.  Efforts  to  map  end-to- 
end  processes  have  required  significant  participation  of  a  number  of  individuals  from  various 
domains  for  extended  periods  of  time. 

The  Air  Force  has  had  difficulty  in  driving  business  process  change  and  minimizing 
unnecessary  customization.  This  is  partly  because  of  resistance  to  change  and  the  lack  of  an 
effective  mechanism  or  process  to  foster  cross-domain  tradeoffs,  except  for  individual  cases  of 
motivated  senior  leadership.6  This  includes  a  lack  of  governance  to  adjudicate  BPR/process 
changes  across  the  business  enterprise.  A  lack  of  leaders,  at  all  levels,  who  can  make  decisions 
that  are  binding  on  their  communities  has  also  hindered  business  process  change.7  Additionally, 
some  regulations  and  policies  that  levy  requirements  to  interface  with  external  systems  drive 
customization  of  Air  Force  ERP  systems.8 

Exacerbating  these  problems  for  the  Air  Force  is  the  lack  of  a  systematic  approach  to  get 
from  the  AS-IS  processes  to  desired  TO-BE  processes.  While  many  methodologies  have  been 
developed  over  the  past  two  decades  that  describe  BPR  activities  on  a  strategic  and  tactical  level, 
specific  operational  details  on  how  to  get  from  the  AS-IS  to  the  TO-BE  processes  are  sparse. 


4 

An  architecture  is  a  formal  blueprint  for  methodically  and  completely  defining  an  organization’s  operational 
processes  and  enabling  environment  (U.S.  Air  Force,  201  lb). 

5  This  report  by  GAO  concludes  that  while  the  Air  Force  “has  a  long-standing  effort  to  develop  and  use  an 
enterprise  structure,  they  have  much  to  do  before  their  efforts  are  considered  mature.” 

6  The  logistics  financials  were  initially  to  be  part  of  the  Air  Force’s  financial  ERP,  DEAMS.  When  it  was 
discovered  that  the  design  for  ECSS  would  require  significant  customization  in  order  to  transfer  the  necessary  data 
between  ECSS  and  DEAMS,  the  decision  was  made  to  include  them  in  ECSS.  This  decision  had  to  be  made  by  the 
logistics  and  financial  functional  leaders,  instead  of  being  driven  by  an  Air  Force  business  strategy. 

7  In  the  Air  Force,  responsibility  for  doing  BPR  is  currently  shared  by  both  the  PMO  and  FMO.  However, 
documentation  of  the  precise  roles  and  responsibilities  could  not  be  identified  by  the  RAND  research  team. 

g 

In  the  private  sector,  the  ERP  will  replace  as  many  systems  as  possible  to  leverage  the  ERP  capabilities  for  end-to- 
end  processes.  In  the  DoD,  the  ERP  may  only  be  implemented  within  a  certain  functional  domain.  This  requires 
additional  interfaces  to  be  created.  For  example,  ECSS  has  the  capability  to  do  electronic  invoicing,  but  the  Air 
Force  must  use  the  Defense  Contract  Management  Agency’s  Wide  Area  Workflow  system  to  handle  electronic 
invoicing. 
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Summary 

BPR  is  pursued  to  achieve  business  improvements,  and  may  be  enabled  by  IT.  It  is  considered  a 
critical  success  factor  to  ERP  implementations,  and  it  helps  an  organization  understand  its 
current  business  processes  and  where  improvements  to  the  business  process  can  and  should  be 
implemented.  For  BPR  to  succeed,  top  management  must  support  the  initiative  and  communicate 
the  goals  and  objectives  of  the  BPR  activity.  Senior  leadership,  middle  management,  and  support 
staff  must  have  sufficient  knowledge  of  BPR;  and  the  organizational  and  incentives  structure 
must  support  a  cooperative  environment  that  fosters  communication,  confidence  and  trust. 
However,  the  Air  Force  has  faced  a  number  of  obstacles  in  achieving  these  conditions  for 
success,  including  the  lack  of  an  overall  strategy  with  respect  to  business  transformation,  process 
change,  and  minimizing  unnecessary  customization,  as  well  as  documenting  the  AS-IS  and 
developing  the  TO-BE  processes. 
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5.  Organizational  Change  Management 


As  has  been  discussed,  transformational  efforts,  including  those  associated  with  ERP  system 
implementations,  typically  affect  a  large  number  of  organizations  and  processes.  While  change  in 
general  can  be  difficult  to  navigate,  the  tension  and  disruption  involved  in  a  business 
transformation  and  ERP  implementation  are  somewhat  unusual.  For  example,  the  integration, 
transparency,  and  process-oriented  management  enabled  by  an  ERP  system  are  often  highly 
valued  by  top-level  leadership,  but  can  be  at  odds  with  an  organization’s  structure,  processes, 
and  culture.  This  is  particularly  true  for  hierarchical  organizations  structured  around 
independently  operating,  or  stovepiped,  business  units,  as  is  the  case  with  the  military  services 
and  most  defense  agencies  (Gulledge  and  Sommer,  2003).  An  ERP  implementation  and 
associated  transformational  activities  can  also  be  seen  as  unwelcome  intrusions  and  disruptions 
to  mission  objectives  by  managers  and  employees  in  general.  Not  only  can  there  be  apprehension 
regarding  the  time  and  effort  needed  to  learn  to  use  the  new  system  and  associated  processes,  but 
early  planning  activities  themselves  require  significant  time  and  effort  from  key  personnel. 

For  these  reasons,  transfonnational  efforts,  especially  those  associated  with  an  ERP 
implementation,  can  be  met  with  apathy,  skepticism,  and  resistance  at  all  levels  of  the 
organization.  Numerous  past  failures  of  DoD  ERP  implementation  attempts  have  only  intensified 
the  expected  skepticism  and  apprehension  regarding  current  transformative  ERP  efforts  across 
the  defense  community.  Without  active  support  of  the  community,  these  activities  will  fall  short 
of  realizing  the  desired  benefits — at  best — and  fail,  at  worst.  OCM  is  a  term  used  to  describe  an 
organization’s  efforts  to  garner  support  for  changes,  and  encourage  their  adoption.  Our  literature 
review  found  OCM  to  be  one  of  the  most  important  factors  for  successful  ERP  implementations 
(Finney  and  Corbett,  2007;  Somers  and  Nelson,  2001),  but  one  that  has  at  times  been 
underappreciated  (GAO,  2008). 

Conditions  for  Success 

OCM  initiatives  can  involve  both  formal  and  informal  tactics;  however,  the  overall  OCM 
strategy  should  be  a  formalized,  well-defined,  and  high-priority  part  of  the  overall 
transformation.1  OCM  activities  need  visible  support  from  the  highest  levels  of  leadership  and 
should  be  synchronized  with  the  business  case  in  order  to  be  fully  effective.  Specific  activities 
include  stakeholder  analyses,  formal  and  informal  communication,  education,  and  training. 

These  should  target  and  involve  all  levels  of  the  organization  throughout  all  phases  of  the  effort 
(Abdinnour-Helm,  Lengnick-Hall,  and  Lengnick-Hall,  2003). 


Several  consulting  firms  and  systems  integrators  have  developed  their  own  frameworks  and  methods  for 
developing  OCM  strategies.  These  strategies  are  widely  used  in  both  the  public  and  private  sector. 
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Active  Leadership  Support 

The  importance  of  strong  leadership  support  during  any  transformational  effort  is  underscored  by 
the  vast  body  of  literature  on  the  topic  and  comments  made  by  those  we  interviewed  (Somers  and 
Nelson,  2001;  Jarvis,  2004;  Lopez-Estrada,  2006;  Finney  and  Corbett,  2007;  Panorama 
Consulting  Group,  2010;  Defense  Business  Board,  2011).  As  one  OCM  lead  from  a  DoD  ERP 
program  stated,  “Organizational  change  management  is  not  just  propaganda  and  factsheets.  It’s 
the  senior  leaders’  message  from  the  highest  level  to  the  troops  that  matters.” 

Synchronization  with  the  Business  Case 

OCM  and  business  case  development  and  use  should  be  closely  coordinated,  as  has  been 
mentioned  above.  According  to  Poti  and  Kamalanabhan  (2009)  and  many  other  authors 
contributing  to  OCM  and  ERP  literature,  an  informed  understanding  of  objectives  and  rationale 
on  the  part  of  employees  makes  the  management  of  change  much  easier.  Framing  goals  and 
objectives  in  the  business  case  in  a  way  that  considers  organizational  values  and  culture  will  be 
more  likely  to  encourage  deep  support  and  commitment  than  technical  goals  without  a  clear 
connection  to  organizational  values  (Ostroff,  2006).  Lastly,  the  business  performance  metrics 
identified  in  the  business  case  can  be  used  to  demonstrate  early  successes  and  will  likely  be  more 
persuasive  than  metrics  that  demonstrate  only  technical  improvements  (Russell,  2006).  The 
usefulness  of  this  best  practice  was  demonstrated  in  data  improvement  efforts  for  the  ECSS 
program,  where  middle-management  support  was  fostered  through  the  demonstration  of  business 
improvements  independent  of  system  deployment. 

Stakeholder  Analysis 

One  of  the  first  activities  to  take  place  under  the  OCM  strategy  should  be  a  stakeholder  analysis, 
which  provides  awareness  of  the  beliefs,  priorities,  and  equities  of  all  internal  and  external 
stakeholders.  This  awareness  will  achieve  the  following  effects  (Ward  and  Daniel,  2006): 

•  reveal  organizational  “sticking  points”  to  be  monitored  throughout  the  transformation 
(e.g.,  stakeholder  groups  with  a  high  “pain-to-gain”  ratio) 

•  enable  the  necessary  tailoring  of  communications,  education,  and  trainingi 2 

•  inform  the  feasibility  of  achieving  desired  benefits 

•  inform  the  best  strategy  for  achieving  desired  benefits.3 

Negative  sentiments  in  one  community  can  easily  spread  across  others,  potentially  undermining 
the  effort.  It  is  therefore  important  to  identify  and  consider  beliefs,  priorities,  and  equities  of  all 
stakeholders  early  on.  The  first  stakeholder  analysis  should  be  completed  before  the  finalization 
of  the  business  case  (Ward  and  Daniel,  2006).  The  analysis  should  then  be  updated  periodically 

i 

~  The  tailoring  of  OCM  activities  has  been  found  to  be  important  by  several  researchers  (Abdinnour-Helm, 
Lengnick-Hall,  and  Lengnick-Hall,  2003;  Ward  and  Daniel,  2006). 

3 

For  example,  some  ERP  consulting  fimis  recommend  that  roll-outs  begin  within  organizations  that  are  ready  and 
eager  and  that  will  more  easily  adopt  the  system.  Beginning  roll-outs  with  these  organizations  will  allow  for  early 
demonstrations  of  success,  which  will  build  momentum  and  support  for  the  initiative. 
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as  key  decisions  are  made  that  change  the  trajectory  of  the  effort.  The  decision  to  pursue  an  ERP 
system  as  part  of  business  transformation  would  be  one  such  decision  requiring  an  update  to  the 
stakeholder  analysis. 

Employee  Involvement 

Keeping  employees  from  all  levels  of  the  organization  involved  throughout  the  effort  will 
facilitate  the  discovery  of  issues  unforeseen  by  management  and  will  increase  buy-in  among  the 
community  (Wagner  and  Antonucci,  2004;  Sommer,  2006;  Poti  and  Kamalanabhan,  2009). 
Individuals  from  different  echelons  will  see  the  effects  of  proposed  changes  from  different 
perspectives.  Also,  involvement  will  reassure  employees  that  their  perspective  is  valued  and  will 
not  be  ignored.  Finally,  simple  exposure  to,  and  direct  experience  with,  newly  proposed  ideas 
may  also  breed  comfort  and  enthusiasm  within  the  community  (Abdinnour-Helm,  Lengnick- 
Hall,  and  Lengnick-Hall,  2003). 

Communication 

Consistent,  two-way  communication  should  also  begin  as  early  in  the  transformational  efforts  as 
possible  to  establish  an  understanding  of  the  key  objectives,  eliminate  apprehensive  speculation, 
provide  exposure  to  new  ideas,  and  manage  expectations  (Bearing  Point,  2004;  Russell,  2006; 
Phelan,  2007;  Panorama  Consulting  Group,  2010).  This  communication  should  begin  from  the 
top  of  the  organization  and  eventually  flow  from  multiple  channels  and  voices.4  Regardless  of 
the  delivery  vehicle,  the  objectives  and  vision  as  defined  in  the  business  case  should  provide  the 
major  focus  of  communications.  As  the  project  evolves  and  decisions  are  made,  messages  may 
become  more  detailed  but  should  not  stray  from  this  central  focus  (Fernandez  and  Rainey,  2006; 
Ward  and  Daniel,  2006).  Where  possible,  enterprise  benefits  and  changes  should  be  translated  to 
a  “lower  level”  so  that  employees  understand  how  their  jobs  may  be  affected  (King  and  Brook, 
2007).  It  should  be  clear  to  the  community  at  large  that  leadership  is  aware  of  any  potential 
“disbenefits”  and  will  work  to  compensate  for  them  (Sarker  and  Lee,  2003;  King  and  Brook, 
2007).  Lofty  goals  should  be  communicated  to  challenge  employees’  thinking  as  they  carry  out 
transformational  activities,  such  as  BPR  (Ostroff,  2006).  However,  promises  made  regarding 
immediate  benefits  or,  when  applicable,  system  performance  should  not  set  expectations 
unreasonably  high. 

As  part  of  the  communications  effort,  the  community  at  large  should  be  given  the 
opportunity  to  provide  feedback  and  ask  questions,  because  this  will  allow  for  better  awareness 
of  issues  unseen  by  management  and  will  give  employees  a  sense  that  their  concerns  are 
seriously  considered  (Kirchmer,  2006;  King  and  Brook,  2007). 


4 

Examples  include  informational  websites,  Q&A  sessions,  staff  meetings,  fact  sheets,  and  general  announcements, 
among  others. 
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Education  and  Training 

In  any  transformational  effort,  education  and  training  will  be  needed  throughout  the  process  and 
should  address  more  than  just  use  of  a  new  IT  system.  For  example,  education  and  training  will 
be  required  for  individuals  who  will  be  involved  in  planning  transformational  efforts  before  the 
onset  of  those  activities,  as  well  as  during  them  (Panorama  Consulting  Group,  2010).  In  fact, 
OCM  in  general  is  often  cited  as  a  critical  success  factor  for  BPR  (Somers  and  Nelson,  2001; 
Abdolvand,  Albadvi,  Ferdowsi,  2008).  Also,  top-level  leadership  needs  to  be  educated  on  the 
nature  of  any  proposed  technological  solutions  in  order  to  gain  a  better  understanding  of  where 
and  why  their  involvement  and  support  are  necessary.5  Additionally,  individuals  may  need 
training  in  the  knowledge  and  skills  to  perform  new  processes.6  Finally,  it  is  important  to  provide 
adequate  user  training  and  help-desk  support  as  technological  solutions  are  introduced. 

Challenges 

Despite  general  awareness  of  OCM’s  importance  in  ERP  implementations,  Air  Force  ERP 
programs  have  struggled  to  overcome  organizational  challenges  for  several  reasons.  Some 
stemmed  from  the  structure  of  the  institution  itself,  which  poses  serious,  though  not 
insurmountable,  obstacles.  The  teams  chartered  to  guide  OCM  efforts  faced — and  some  still 
face — a  difficult  task.  However,  there  were  areas  in  which  improvements  could  have  been  made, 
many  of  which  would  have  required  more  resources.7 

Stovepiped  Organizational  Structure  and  Culture 

The  Air  Force’s  stovepiped  structure  and  culture  have  not  easily  enabled  or  embraced  key  ERP 
planning  activities  aimed  at  improving  processes.  Competing  interests  and  initiatives  across 
functional  stovepipes  have,  at  times,  kept  one  functional  part  of  the  organization  from  optimizing 
enterprise  business  processes  or  sharing  scarce  resources  to  support  the  initiatives  of  another. 

Our  discussions  with  FMO  staff  in  at  least  two  programs  revealed  that  cultural  challenges 
hampered  process-planning  activities.  For  example,  during  process  planning  activities,  there  was 
a  tendency  to  confuse  current  business  processes  with  the  purpose  of  these  processes  (e.g.,  some 
had  a  hard  time  generalizing  a  statement  such  as,  “submit  fonn  XX- YY”  to  the  more 
appropriately  stated,  “submit  a  purchase  order”).  The  same  tendency  was  also  revealed  during 
training,  where  it  was  found  that  many  employees  understood  their  job  functions  at  only  a  rote 


5  One  ERP  OCM  consultant  we  interviewed  described  a  weekend-long  retreat  taken  by  Army  leadership  before  the 
kick-off  of  an  ERP  program.  This  retreat  was  helpful  in  educating  these  individuals  on  potential  pitfalls  and  best 
practices.  A  weekend  retreat  was  necessary  because  these  individuals  were  unable  to  find  adequate  time  during  work 
hours  to  study  and  discuss  these  issues. 

6  In  order  for  this  training  to  be  done  well,  AS-IS  and  TO-BE  processes  need  to  be  well  defined  and  documented. 

7  Several  consulting  firms  have  provided  rough  estimates  for  OCM  budgets.  Most  state  that  OCM  costs  should  make 
up  about  9  percent  to  12  percent  of  the  overall  program  costs.  Given  the  organizational  challenges  present  in  the  Air 
Force  context,  it  is  reasonable  to  assume  that  such  costs  would  not  be  less  than  these  estimates,  which  were 
developed  within  an  arguably  more  flexible  private-sector  context. 
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level,  making  process  training  a  challenge.  Another  cultural  challenge  described  by  functional 
staff  related  to  attitudes  regarding  decisionmaking:  Often  decisions  that  needed  to  be  made  by 
top-level  leadership  were  wrestled  with  for  too  long  at  lower  levels.  This  occurred  out  of  a  fear 
that  bringing  problems  to  one’s  boss  would  be  seen  as  a  sign  of  failure.  Finally,  the  past 
experience  of  DoD  ERP  programs  has  been  generally  unsuccessful  and  has  bred  some  skepticism 
regarding  new  ERP  programs  within  the  Air  Force  community. 

Leadership  Turnover  and  Limited  Options  for  Incentives 

Two  other  structural  challenges,  high  leadership  turnover  and  limited  options  for  incentives,  are 
interrelated.  Without  a  consistent  vision  and  message  streaming  from  high-level  leadership 
(“above”  the  program  manager),  interest  and  commitment  can  wane  throughout  the 
transformation  (Kelman,  2005).  The  two-  to  four-year  rotations  for  senior  military  officers  and 
political  appointees  can  make  maintaining  this  consistency  difficult  for  the  simple  reason  that 
individuals  will  have  different  ideas  and  goals  coming  into  the  job.  Furthermore,  individuals  in 
these  positions  may  be  motivated  to  focus  on  initiatives  that  will  show  immediate  benefits  rather 
than  on  initiatives  that  will  not  provide  benefits  until  after  they  have  moved  on.  Current  reward 
structures,  particularly  those  for  middle  management,  often  incentivize  performance  within  a 
particular  function  or  community  and  do  not  encourage  optimization  of  business  perfomiance 
across  the  enterprise  level.  Instead,  incentives  typically  reward  suboptimization  within 
suborganizations.  Incentives  asserted  to  be  effective  in  the  public  sector  by  individual  experts  we 
interviewed  included  the  use  of  performance  plans  and  reviews,  promotion,  and  the  allure  of  new 
roles  and  responsibilities  (Oliver  and  Romm,  2002;  Sommer,  2011). 

Narrowly  Focused  OCM  Efforts 

Air  Force  ERP  programs  faced  challenges  in  establishing  and  maintaining  a  broad  scope  for 
OCM  throughout  the  life  of  the  program.  First,  while  early  OCM  plans  may  have  carried  the 
intent  to  target  each  level  of  the  organization  and  all  aspects  of  change,  many  of  the 
communications  over  time  became  focused  solely  on  the  receiving  community  and  on  system 
performance.  This  narrowing  of  focus  was  generally  due  to  limited  or  diminishing  funds  as 
acquisition  issues  arose,  causing  delays.  Second,  it  was  unclear  whether  there  were  concerted 
OCM  efforts  focused  specifically  on  BPR  or  other  process-planning  activities  in  any  of  the 
programs.  More  than  one  individual  confirmed  that  BPR  efforts  were  hampered  by  anxiety 
regarding  “efficiencies”  and  job  security.  This  anxiety,  combined  with  the  tendency  of  some  to 
confuse  the  mechanics  of  a  process  with  its  objective,  often  resulted  in  legacy  processes  being 
upheld  as  the  best  or  only  way  to  perform  a  particular  action.  Finally,  a  recent  GAO  report 
revealed  DEAMS  training  for  DFAS  personnel  did  not  fully  address  all  user  needs  (GAO,  2012). 

Stakeholder  Analyses 

The  stakeholder  analyses  provided  to  us  by  FMOs  included  the  identification  of  stakeholders’ 
influence  and  impact  on  the  program,  but  did  not  assess  commitment  or  beliefs  regarding  the 
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program.8  Stakeholder  analyses  were  also  not  considered  as  seriously  as  the  literature 
recommends  in  the  finalization  of  the  business  case  and  benefits  realization  plans. 

Unrealistic  User  Expectations 

We  found  that  user  expectations  for  some  ERP  efforts  were  not  appropriately  managed  and  at 
times  were  inaccurate.  Our  interviews  revealed  that  many  users  did  not  fully  understand  which 
system  functionalities  they  would  be  receiving  upon  roll-out.  In  another  cases,  user  complaints 
regarding  system  functionality  and  fonn  were  met  with  significant  system  modifications  when 
they  could  have  been  handled  with  further  education  and  training.  Moreover,  when  ERP  systems 
“went  live,”  performance  was  often  poorer  than  expected  due  to  unanticipated  incompatibilities 
with  the  Air  Force  network  and  legacy  data.  Delays  in  acquisition  schedules  due  to  these  issues 
and  in  general  have  resulted  in  loss  of  interest  and  enthusiasm  at  all  levels  of  the  organization. 
Miscommunications  and  misunderstandings  between  the  PMOs  and  FMOs  in  multiple  programs 
hindered  efforts  to  coordinate  acquisition  and  OCM  activities  to  troubleshoot  these  problems. 
This  lack  of  coordination  at  times  led  to  the  dissemination  and  use  of  outdated  OCM  material, 
such  as  training  and  communication  materials. 

Summary 

Managing  the  elusive  and  constantly  changing  organizational  challenges  during  business 
transformation  is  a  tall  order  and  has  been  a  challenge  for  the  Air  Force,  but  there  is  reason  to 
expect  success  in  the  future.  The  DoD  now  has  experience  with  ERPs  and  much  has  changed 
since  it  first  pursued  ERPs  decades  ago.  First,  people  in  general  are  more  used  to  technology. 
Second,  the  Air  Force  community  has  had  ample  time  to  acclimate  to  the  idea  of  ERP  systems. 
Lastly,  today’s  ERP  systems  are  more  configurable,  which  may  mean  adopting  organizations 
will  be  forced  to  make  fewer  trade-offs  between  customization  and  painful  organizational 
changes.  These  factors  may  make  changes  easier  for  the  Air  Force  community  in  future 
transformational  and  technological  endeavors. 


g 

Conversations  with  the  AF-IPPS  FMO  revealed  that,  despite  efforts  to  receive  more  OCM  funding,  their  two- 
person  Strategic  Outreach  Office  (their  version  of  OCM)  does  not  have  sufficient  resources  or  manpower  to  conduct 
such  a  stakeholder  analysis. 
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6.  IT  Acquisition 


In  all  but  the  rarest  cases,  technology  should  not  drive  business  system  selection.  Any  of  the 
technology  alternatives  discussed  below  can  be  made  to  work  given  sufficient  time  and 
resources.  However,  some  are  better  suited  to  achieving  particular  organizational  objectives  than 
others.  Therefore,  clear  thinking  about  enterprise  goals,  constraints  and  expectations  in  the  initial 
planning  stages  is  crucial.  Once  these  goals  and  expectations  are  set,  they  should  be  consistently 
reinforced  through  communication,  acquisition  activities,  metrics,  incentives,  and  governance  to 
develop  shared  commitment  of  all  parties. 

Conditions  for  Success 

Once  the  enterprise  objectives  have  been  decided  upon  and  communicated,  and  initial  BPR  has 
been  done,  planning  for  the  enabling  IT  can  begin.  The  selection  of  the  IT  system  and  its 
implementation  strategy  should  flow  from,  and  be  consistent  with,  the  business  case.  This 
linkage  should  guide  the  many  decisions  that  must  be  made  during  development  and  deployment. 
We  will  discuss  some  specific  issues  that  must  be  carefully  weighed. 

System  Scope 

One  of  the  first  considerations  in  developing  the  architecture  for  the  system  solution  is  the 
number  of  functional  or  organizational  boundaries  that  will  be  crossed.  While  crossing  these 
boundaries  is  one  of  the  defining  characteristics  of  a  true  end-to-end  process,  complexity,  and 
thus  risk,  typically  increase  with  the  number  and  diversity  of  these  boundaries.  While  these 
challenges  can  be  addressed  through  effective  governance  and  management,  they  should  be 
given  serious  consideration  during  program  planning  and  actively  monitored  by  enterprise 
leadership  during  execution. 

Functional  Domain 

A  system  for  a  well-structured  domain  (e.g.,  supply)  will  be  simpler  to  develop  and  implement 
than  one  for  a  more  complex  domain  (e.g.,  maintenance).  Complex  domains  will  require  more 
effort  in  the  pretransformation  phase  to  fully  specify  the  AS-IS  processes,  and  more  coordination 
is  needed  in  the  pre-  and  post-program  initiation  phases  to  develop  TO-BE  processes  that  will 
meet  or  exceed  the  business  objectives.  Complex  processes  will  also  likely  require  more  objects 
pertaining  to  reports,  interfaces,  conversions,  and  extensions  (RICE).1  For  these  complex 
domains,  the  potential  benefits  of  greater  integration  should  be  realistically  weighed  against  the 
challenges. 


1  RICE  objects  refer  to  modifications  to  the  standard  ERP  software  functionality  to  meet  specific  customer 
requirements. 
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Legacy/Trading  Partner  Systems 

In  the  case  of  ERP  systems,  one  aspect  of  planning  cited  by  a  number  of  interviewees  as  being 
done  inadequately  was  the  assessment  of  the  existing  systems  that  would  interact  with,  or  be 
replaced  by,  the  new  system.  The  functionality,  data  structures  and  sources,  users,  performance, 
reports,  and  analytic  capabilities  of  the  existing  system(s)  should  be  documented  and  available  to 
the  development,  BPR  and  OCM  teams.  Similarly,  the  characteristics  of  external  systems  that 
will  interact  with  the  ERP,  particularly  their  interface  requirements  and  any  planned 
modifications,  need  to  be  understood  by  the  ERP  team.  Since  interfaces  to  external  systems  can 
drive  costs  and  schedules,  the  number  of  these  systems  and  owners  can  add  complexity  and  risk. 

Characteristics  of  AS-IS  Environment 

While  an  accurate  characterization  of  the  AS-IS  processes  and  environment  is  most  important  as 
a  baseline  for  the  business  case  analysis  and  as  a  point  of  departure  for  the  BPR  activities,  it  is 
also  useful  for  the  selection  and  design  of  the  technology  solution.  Costs  and  limitations  of 
existing  systems  and  processes  need  to  be  understood  to  support  accurate  assessment  of 
alternatives.  From  a  system  development  perspective,  the  most  critical  aspect  of  the  AS-IS 
environment  is  the  nature,  volume,  and  quality  of  the  data.  Often  the  existing  databases  have 
many  missing  or  incorrect  entries,  which  are  bypassed  or  ignored  since  they  may  not  be 
necessary  for  the  AS-IS  process.i 2  However,  an  ERP  system,  with  its  high  degree  of  integration 
and  extensive  data  manipulation  capabilities,  depends  on  authoritative  data.  Because  data  quality 
is  so  important  to  establishing  confidence  in  the  system,  ERPs  have  data  validation  processes 
built  in.  Undiscovered  problems  with  data  have  resulted  in  massive  problems  when  systems  “go 
live.”  While  many  were  initially  assumed  to  be  errors  within  the  ERP,  further  investigation 
revealed  previously  undiscovered  or  underappreciated  problems  with  the  source  data.  Correcting 
these  problems  can  require  substantial  time  and  effort,  but  is  much  less  disruptive  if  done  in 
advance. 

Technology  Alternatives  for  TO-BE  Environment 

There  are  a  variety  of  IT  system  alternatives  for  modernizing  business  systems.  Each  should  be 
fully  evaluated  against  the  enterprise  goals  and  constraints  specified  in  the  business  case.  While 
we  describe  discrete  alternatives  below,  many  private-  and  public-sector  organizations  have 
found  that  some  combination  of  them  may  provide  the  most  advantageous  solution  for  a 
particular  situation  (Michael,  2012). 

Legacy  System  Retention/Modification 

The  most  obvious  alternative  is  to  retain  or  modify  the  existing  system  or  systems.  Whether  this 
is  a  competitive  option  will  depend  on  several  considerations: 


i 

~  In  one  case,  pre-implementation  testing  showed  that  as  much  as  80  percent  of  the  legacy  data  would  be  rejected  by 
the  ERP  system. 
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•  Functionality:  How  well  does/can  it  meet  local  and  enterprise  requirements? 

•  Priority:  How  critical  is  the  function?  Is  the  system  performance  adequate  for  the  near- 
term?  How  expensive  will  it  be  to  make  any  necessary  modifications? 

•  Flexibility:  How  easily  can  the  system  be  adapted  to  accommodate  changes  in 
requirements,  organizations,  and  its  operating  environment? 

•  Interfaces:  How  many  and  how  complex  are  the  interfaces  with  other  systems? 

•  Maintainability:  What  are  the  costs  and  availability  of  appropriate  skills,  tools,  and 
documentation  to  support  system  maintenance?  Is  the  system  sufficiently  modular  to 
support  cost-effective  modification  and  testing  of  components  without  involving 
unrelated  parts  of  the  system? 

Specialized  Off-the-Shelf  Applications 

Another  alternative  is  to  use  or  adapt  an  “off-the-shelf’  application,  either  developed  by  a 
commercial  firm  (COTS)  or  by  another  government  organization  (GOTS).  If  developed  by  a 
vendor  to  provide  specialized  functionality  and  embraced  by  a  variety  of  customers,  it  is  often 
referred  to  as  “best  of  breed.”  We  summarized  the  advantages  and  disadvantages  of  COTS  and 
GOTS  in  Table  6.1. 

Table  6.1.  Specialized  COTS/GOTS  Advantages  and  Disadvantages 


COTS/GOTS  Advantages 


COTS/GOTS  Disadvantages 


•  Suitability  to  its  intended  purpose  is 
usually  high  because  of  its  focus  on 
specific  functions. 

•  Can  be  implemented  relatively  quickly 
because  little  or  no  new  development  is 
required. 

•  Cost  can  be  lower  than  other 
modernization  alternatives  because  the 
development  (and  in  some  cases  the 
maintenance  and  upgrade)  costs  are 
amortized  over  a  larger  user  base. 


Off-the-shelf  functionality  may  not  meet  all  the  organization’s 
requirements.  (Modifications  to  a  proprietary  system  can  be 
expensive  and  may  not  be  supported  by  the  vendor.) 

At  some  point,  vendors  will  stop  supporting  older  versions  of 
their  software,  forcing  customers  to  upgrade  to  a  newer 
version. 

Operating  a  variety  of  systems  complicates  IT  operations  in 
areas  such  as  interface  development  and  testing,  system 
maintenance,  user  training,  and  help  desk  functions. 
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ERP 


ERP  systems  present  some  compelling  advantages  over  other  alternatives  for  modernizing 
today’s  DBSs,  as  indicated  in  Table  6.2. 

Table  6.2.  ERP  Advantages  and  Disadvantages 


ERP  Advantages 


ERP  Disadvantages 


•  Integrates  a  wide  range  of  related  business  functions 
into  a  single  system  using  common  data. 

•  Incorporates  “best”  (or  at  least  most  common) 
practices  for  each  of  the  core  functions. 

•  Structured  around  end-to-end  business  processes 
rather  than  individual  functions  thus  streamlining 
performance. 

•  Can  serve  as  a  forcing  function  for  transformation 
(assuming  active  commitment  by  leadership). 

•  Requires  disciplined  approach  to  process  and  data 
definition,  encouraging  rationalization  and 
consistency. 

•  Can  replace  multiple  systems  simplifying  cross¬ 
functional  transactions,  communication,  analysis. 

•  Sustainment  is  simplified  by  common  system  and 
data  across  multiple  organizations  and  by  vendor- 
provided  support. 

•  Training  is  simplified  by  common  user  interfaces. 

•  Can  be  implemented,  at  least  in  theory,  with  less 
development  risk  and  in  less  time  than  most 
alternatives  of  similar  scope,  assuming  it  is  treated 
as  a  COTS  product. 

•  Continuing  vendor  support  and  upgrades  reduce 
Lifecycle  Cost/IT  staff  workload. 


•  Realigning  processes  to  match  the  software 
requires  substantial  effort  and  cooperation  across 
affected  entities,  which  are  often  underestimated. 

•  Modification  to  add  unsupported  capabilities  (as 
opposed  to  configuration  of  existing  functionality) 
can  be  expensive  and  time  consuming,  both 
during  implementation  and  sustainment. 

•  Requires  specialized  expertise  to  design  and 
implement  the  system  efficiently  and  effectively. 

•  Commits  the  organization  to  a  proprietary  solution 


Custom  Development 

Custom  business  systems  range  from  locally  developed  ad  hoc  software  for  specialized 
applications  to  centrally  managed  systems  in  common  use  across  the  Air  Force  or  DoD.  Until 
fairly  recently,  this  was  the  default  approach  to  obtaining  IT  capability  in  DoD.  However,  the 
proliferation  of  these  custom  systems  has  resulted  in  an  increasingly  complex  and  expensive 
operational  and  sustainment  environment.  The  services,  OSD,  and  Congress  are  all  taking 
actions  to  reduce  duplication  and  inefficiencies  by  increasing  visibility  and  centralizing  approval 
for  new  systems.  However,  in  situations  where  process  requirements  are  highly  specialized, 
custom  software  may  still  be  the  appropriate  choice.  Table  6.3  summarizes  the  advantages  and 
disadvantages  of  custom  development. 
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Table  6.3.  Custom  Development  Advantages  and  Disadvantages 


Custom  Development  Advantages 


Custom  Development  Disadvantages 


•  High  suitability  to  purpose.  This  is  particularly  true 
where  other  options  involve  unacceptable 
compromises,  because  of  mission  criticality  and/or 
unique  requirements. 

•  Simplified  governance/decisionmaking  (assuming 
more  limited  scope  than  ERP  and  crossing  fewer 
organizational  boundaries). 


•  Higher  cost  and  risk  than  COTS/GOTS. 

•  Often  leads  to  inefficient  duplication  of  capabilities 
and  resources  across  organizations. 

•  Can  complicate  current  and  future 
transformation/integration . 

•  Requires  tailored  sustainment. 

•  Upgrades/modifications  typically  expensive. 


SOA 

Service-oriented  architecture  (SOA)  is  not  a  technology  but  an  architectural  approach 
characterized  by  a  set  of  standards  that  allow  independent  services  to  be  discovered  and  accessed 
over  a  network  through  standard  protocols  (typically  Web  services).  These  services  can  be 
combined  by  users  in  various  ways  for  various  purposes.  Since  their  structure,  platform,  and 
operation  are  isolated  from  users  of  the  service,  they  can  be  developed  and  maintained 
independently.  The  result  is  a  distributed  heterogeneous  architecture  using  shared  services  that 
functions  based  on  common  protocols.  Table  6.4  summarizes  the  advantages  and  disadvantages 
of  SOA. 


Table  6.4.  SOA  Advantages  and  Disadvantages 


SOA  Advantages  SOA  Disadvantages 


Provides  architecture  and  data  standards  enabling 
multiple  applications  to  use  shared  services  and 
data. 

Can  be  used  with  any  of  the  alternatives  discussed 
above. 

Can  extend  the  useful  life  of  legacy  systems  and 
allow  for  phased  modernization. 

Allows  for  decentralized  development/modification  of 
components. 

Can  provide  increased  flexibility  to  adapt  to  changing 
requirements  or  conditions. 


Not  necessarily  transformative. 

Requires  effective  governance  for  architecture, 
standards  and  enforcement, 
if  components  are  not  used  by  a  variety  of 
applications,  then  economies  are  reduced  or 
eliminated. 

Span  time  for  phased  modernization  delays  the 
modernization  process  substantially. 

Requires  legacy  systems/components  to  be 
brought  into  compliance  with  SOA  standards. 


Availability  of  Qualified  Personnel 

Specialized  expertise  is  needed  to  implement  these  systems.  This  is  particularly  true  in  the  case 
of  ERPs,  where  enterprise  priorities  must  be  communicated  and  reinforced,  the  interests  of 


3 

An  SOA  approach  is  not  a  forcing  function  for  business  process  transformation  because  it  does  not  attempt  to 
dictate  the  internal  operation  of  the  components  or  their  uses  as  an  ERP  would.  If  the  objective  is  incremental 
improvement  of  the  AS-IS  processes,  SOA  can  accommodate  that  as  long  as  the  required  protocols  are  observed. 
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various  stakeholders  must  be  harmonized,  complex  processes  must  be  redesigned,  and  the 
workforce  must  be  motivated  and  retrained.  Experienced  outside  advisers  may  be  needed  to  help 
evaluate  competing  claims,  frame  implementation  choices,  and  assist  in  planning  to  minimize 
unintended  consequences.  Several  programs  noted  the  advantages  of  having  independent 
advisers  in  addition  to  the  implementing  contractor,  supplemented  with  personnel  from  the 
software  vendor.  Finally,  the  incentives  of  these  contractors  must  be  aligned  with  program  and 
enterprise  goals  through  a  combination  of  selecting  appropriate  firms,  active  management,  and 
contractual  incentives. 

Challenges 

In  addition  to  the  challenges  common  to  all  ERP  implementations,  there  are  some  that  are  more 
specific  to  the  DoD  environment. 

DoD  ERP  programs  tend  to  have  many  requirements  and  constraints  related  to  their  public- 
sector  environment  and  their  national  security  mission.  Although  there  is  (or  should  be) 
considerable  commonality  across  the  business  operations  of  the  DoD  components,  there  are  also 
unique  requirements  driven  by  individual  service  missions  and  environments  that  may  preclude 
complete  standardization  of  systems  and  processes.  These  unique  requirements  should  be 
challenged  and  validated,  but  should  not  be  assumed  away  during  the  planning  phase.4  Another 
example  is  that  the  normal  approach  for  delivering  ERP  capability  in  efficient,  useful  increments 
may  have  to  be  modified  to  meet  external  requirements  such  as  service  or  DoD  enterprise  goals 
(e.g.,  auditability  or  impending  retirement  of  legacy  systems)  and  constraints  imposed  by  the 
DoD  acquisition,  funding,  and  certification  processes.  Several  programs  also  noted  that 
limitations  of  the  IT  hosting  environment  can  degrade  business  system  performance 
substantially.  These  limitations  were  often  not  discovered  until  after  system  deployment. 

The  skill  set  and  specialized  knowledge  required  to  design  and  execute  a  successful  ERP 
implementation  are  not  widely  available  within  most  DoD  (or  commercial)  organizations. 
General  experience  in  various  aspects  of  IT  or  DoD  functional  processes,  while  useful,  is  not 
sufficient  for  the  unique  challenges  of  ERP.  Personnel  with  in-depth  knowledge  of  the  business 
processes  involved,  BPR,  the  specific  version  of  the  selected  software  platform,  and  the 
complexities  of  implementing  an  ERP  in  a  large  public-sector  organization  need  to  be  part  of  the 
ERP  team.  Failure  to  ensure  they  are  actively  involved  increases  execution  risk  dramatically.  If 
this  expertise  will  be  provided  by  contractor  support,  personnel  responsible  for  source  selection 
must  critically  evaluate  the  offeror’s  expertise  and  track  record  of  delivering  ERP-relevant 
capability  in  similar  circumstances. 


4 

For  example,  many  world-class  companies  use  commercial  software  systems  for  generic  business  operations  but 
rely  on  custom  software  for  the  critical  functions  that  provide  them  with  a  competitive  edge  (Vogels,  2006;  Soh, 
2005). 
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Summary 

There  is  a  natural  tendency  to  focus  prematurely  on  the  candidate  IT  products  themselves,  before 
more  fundamental  enterprise  considerations  have  been  articulated  and  decided  upon.  In  the  case 
of  ERPs,  this  is  largely  due  to  the  undeniable  appeal  of  an  off-the-shelf  solution  that  purports  to 
provide  “best  of  breed”  functionality — at  lower  development,  training,  and  sustainment  costs; 
within  a  shorter  timeframe;  and  at  lower  risk  because  the  system  has  been  developed  and 
deployed  for  other  users.  ERPs  are  also  seen  as  a  vehicle  for  rationalizing  and  streamlining 
business  processes.  Unfortunately,  realization  of  these  benefits  is  far  from  automatic  and  requires 
substantial  planning,  expertise,  and  commitment  from  all  stakeholders. 

In  addition  to  these  challenges,  which  are  common  to  all  ERP  projects,  there  are  constraints 
peculiar  to  the  public  sector,  such  as  consensus-based  decisionmaking,  highly  constrained  source 
selection  and  acquisition  management  processes,  the  size  and  scope  of  government  operations, 
and  the  lack  of  direct  enterprise  level  metrics,  which  make  implementing  these  systems  even 
more  challenging. 
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7.  Summary  and  Recommendations 


In  this  report,  we  have  defined  success  of  an  ERP-enabled  business  transformation  as  the 
realization  of  business  benefits  aligned  with  enterprise  goals,  within  designated  cost  and 
schedule  constraints.  This  could  become  increasingly  important  to  the  Air  Force  as  today’s 
fiscally  constrained  environment  further  drives  the  need  for  increased  efficiencies  and  savings. 
As  noted  in  the  introduction,  the  conditions  to  realize  success  apply  to  both  the  private  and 
public  sectors.  But  the  Air  Force  faces  challenges  that  increase  the  difficulty  of  achieving  these 
conditions.  Based  on  RAND  interviews  and  literature  reviews,  the  fundamental  motivation  for 
undertaking  an  ERP  acquisition  is  to  enable  business  transformation. 

A  summary  of  the  key  conditions  for  success,  challenges  to  meeting  these  conditions,  and 
recommendations  to  mitigate  these  challenges  are  described  below. 


Key  Conditions  for  Success 

Overall 

•  An  Air  Force  enterprise  business  strategy  supports  the  operational  priorities  of  the  Air 
Force;  outlines  the  business  enterprise  goals  and  objectives;  describes  the  principles, 
goals,  and  objectives  that  are  the  foundation  for  an  Air  Force  Business  Enterprise 
Architecture;  is  the  framework  for  cross-functional  decisionmaking  and  adjudicating 
touchpoints  between  functionals;  and  should  provide  the  foundation  for  any  business 
transformation. 

Business  Case 

•  There  must  be  a  clear  understanding  of  AS-IS  environment  and  of  how  the  desired  TO- 
BE  environment  achieves  enterprise  goals.  These  should  be  documented  in  the  business 
case. 

•  The  business  case  should  articulate  the  business  benefits  and  eventually  include  all 
associated  costs,  risks,  and  a  realistic  schedule. 

•  All  of  these  steps  should  be  completed  before  implementing  the  preferred  solution,  so 
that  the  final  document  can  inform  both  the  enterprise’s  decision  to  commit  resources  to 
carrying  out  the  transformation  and  its  selection  of  a  preferred  solution. 

Governance 

•  The  governance  structure  and  related  decisionmaking  criteria  should  be  grounded  in  the 
business  case. 

•  Governance  should  be  as  simple  and  responsive  as  possible  with  clearly  defined  authority 
and  roles  and  responsibilities. 

•  Ideally,  the  process  should  be  led  by  a  single  person  if  possible,  or  a  small  group. 

•  Air  Force  senior  leadership  should  visibly  support  all  governance. 
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Business  Process  Reengineering 

•  BPR  activities  should  be  conducted  in  support  of  the  business  strategy  and  should, 
predominantly,  be  planned  and  performed  prior  to  any  technology  implementation. 

•  BPR  depends  on  the  business  case  for  its  focus  and  should  drive  the  enterprise’s 
processes  toward  achieving  the  benefits  articulated  in  the  business  case. 

•  BPR  participants  should  seek  to  achieve  the  desired  benefits  through  process  changes  and 
avoid  unnecessary  customization  of  the  technology  solution  to  reflect  legacy  practices. 
Decisionmakers  and  participants  should  maintain  an  enterprise  view  and  optimize  it  even 
if  it  means  suboptimizing  a  particular  functional  area. 

•  Decisionmakers  and  participants  should  have  sufficient  understanding  and  expectations 
regarding  BPR  and  what  it  can  accomplish. 

Organizational  Change  Management 

•  OCM,  a  key  transformation  enabler,  should  be  well  thought  out,  appropriately 
coordinated,  and  provided  with  adequate  resources.  It  should  include  planning  and 
implementation  activities  with  well-defined  implementation  strategies. 

•  While  there  are  formal  processes  for  OCM,  they  should  be  tailored  to  the  specific 
transformation  and  audience. 

•  OCM  is  the  communications,  education,  and  training  avenue  for  the  transformation,  with 
the  business  case  providing  senior  leaders  the  framework  to  provide  a  clear,  consistent 
message. 

IT  Acquisition 

•  If  and  when  it  is  determined  that  an  IT  acquisition  is  required,  the  full  range  of  potential 
alternatives  should  be  evaluated  against  their  ability  to  achieve  the  benefits  stated  in  the 
business  case. 

•  Should  an  ERP  prove  to  be  the  appropriate  solution,  specific  expertise  in  this  technology 
should  be  assigned  to  the  program,  either  organically  or  through  contractors  and 
individual  subject-matter  experts  who  have  proven  expertise  in  similar  engagements. 

•  Careful  attention  should  be  paid  to  tailoring  contractor  incentives  and  motivating  them  to 
help  achieve  the  enterprise  objectives  specified  in  the  business  case. 

Key  Challenges 

Overall 

•  Historically,  there  appears  to  have  been  little,  if  any,  overall  Air  Force-level  business 
strategy  as  described  above;  i.e.,  providing  the  enterprise  vision  for  development  of  a 
business  case,  the  foundation  for  governance,  BPR,  OCM,  and  IT  acquisition. 

Business  Case 

•  In  general,  the  existing  business  cases  do  not  appear  to  capture  benefits  and  enabling 
changes  with  sufficient  detail  before  commencement  of  IT  acquisition.  This  is  due,  in 
large  part,  to  a  poor  understanding  of  the  AS-IS  environment  (i.e.,  processes,  costs, 
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performance)  and  supporting  analyses.  This  absence  of  detail  undermines  the  rigor  with 
which  benefits,  cost,  schedule,  and  risk  are  assessed  in  the  business  case. 

•  There  are  disincentives  to  fully  disclose  some  potential  benefits  (e.g.,  financial  and 
personnel  savings)  because  the  functional  owner  may  not  reap  them  or  control  the 
resources  in  question.  In  many  cases,  the  Air  Force  enterprise  reaps  benefits  (and 
frequently  collects  them  before  realization),  putting  the  functional  at  risk. 

Governance 

•  The  Air  Force  organizational  structure  makes  it  challenging  to  oversee  and  implement 
enterprise  solutions.  The  Air  Force  has  both  the  SECAF  responsible  for  “business”  and 
the  CSAF  for  “operations/command” — with  these  being  further  subdivided  into 
functional  stovepipes.  This  sort  of  hierarchy  can  increase  the  numbers  of  stakeholders, 
driving  more  complicated  governance  structures  and  reducing  efficiency  and 
effectiveness. 

•  Public-sector  governance  has  oversight  dictated  by  law  with  mandatory  compliance — or, 
in  the  case  of  regulations  and  policies,  waiver  requests. 

•  Within  the  public  sector,  senior  leader  turnover  is  the  norm  with  political  appointees  and 
senior  officers  rotating  regularly.  This  can  result  in  uncertainty  in  the  transformation, 
with  critical  decisions  being  delayed  or  deferred  to  incoming  leaders  or  past  decisions 
being  revisited  by  new  leadership  with  different  priorities. 

Business  Process  Reengineering 

•  The  absence  of  an  overarching  business  strategy  has  hindered  the  evolution  and 
convergence  of  financial,  logistics,  and  human  resources  systems  and  processes.  As  a 
result,  decisions  affecting  multiple  functionals  are  not  coordinated  and  adversely  affect 
cost  and  schedule. 

•  The  Air  Force  has  had  difficulty  in  driving  business  process  change  and  minimizing 
unnecessary  customization.  This  is  partly  because  of  resistance  to  change  and  the  lack  of 
an  effective  mechanism  or  process  to  foster  cross-domain  tradeoffs,  except  for  individual 
cases  of  motivated  senior  leadership.  Additionally,  BPR  is  constrained  by  laws, 
regulations,  and  policies  that  can  limit  opportunities  to  change  processes  in  lieu  of  COTS 
customization.  For  example,  to  preserve  a  functional  investment  in  a  particular  system,  a 
policy  may  require  an  interface  to  the  existing  system  instead  of  a  more  efficient 
approach  using  the  functionality  already  available  within  the  COTS  product. 

Organizational  Change  Management 

•  The  large  number  of  stovepipes  in  the  Air  Force  organizational  structure  makes  achieving 
buy-in  to  a  single  solution  difficult.  All  stakeholders  must  be  willing  to  suboptimize  when 
necessary  for  the  good  of  the  enterprise. 

•  OCM  is  narrowly  focused  or  mistimed.  For  example,  at  times  there  was  over-emphasis 
on  communication  and  training  related  to  system  deployment  without  thorough 
orientation  or  training  for  earlier  planning  activities,  such  as  BPR.  At  other  times,  new 
capabilities  were  advertised  too  far  in  advance  of  technology  deliveries  due  to  delayed 
acquisition  schedules.  Lack  of  communication,  or  miscommunication,  between  the  FMOs 
and  PMOs  prevented  effective  mitigation  of  these  issues. 
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•  Stakeholder  analyses  are  not  always  robust  and  are  not  considered  seriously  enough  in 
the  finalization  of  the  business  case  and  benefits  realization  plans. 

IT  Acquisition 

•  DoD  ERP  programs  don’t  lend  themselves  to  generalized  solutions  because  each  presents 
different  opportunities.  Moreover,  if  an  IT  acquisition  is  pursued,  it  is  frequently  subject 
to  constraints  related  to  service  missions,  national  security  requirements,  and  the  laws, 
regulations,  and  policies  imposed  by  higher-level  organizations.  This  has  the  potential  to 
drive  the  phasing  of  program  activities,  the  number  of  interfaces,  and  a  variety  of  other 
aspects  of  program  execution,  thereby  increasing  complexity — and  ultimately,  program 
cost  and  schedule. 

•  Some  IT  acquisitions  require  specialized  skill  sets  to  develop  and  implement  effectively. 
An  ERP  is  one  such  example.  As  they  are  relatively  few  in  number  with  extended 
implementation  schedules,  these  may  occur  “once  in  a  career”  and  do  not  lend  themselves 
to  development  of  widespread  or  deep  organic  expertise. 

Recommendations 

Below  we  present  our  recommendations  for  mitigating  the  above  planning  challenges  in  three 
time  phases:  Pretransformation,  in  which  the  initial  conditions  for  transformation  are 
established;  Transformation,  Preprogram  Initiation,  in  which  all  the  activities  leading  up  to  a 
materiel  decision  are  performed;  and  Transformation,  Post-Program  Initiation,  in  which 
activities  following  the  decision  to  pursue  an  IT  acquisition  are  carried  out.  Our  challenges  and 
recommendations  are  summarized  in  Table  7.1. 

Table  7.1.  Summary  of  Challenges  and  Recommendations 


Challenges 


Recommendations 


•  Lack  of  an  overall  Air  Force-level  business 
strategy  that  is  endorsed  by  both  the 
business  (SECAF)  and  command  (CSAF) 
sides  of  the  Service. 


The  Air  Force  CMO  (USECAF)  should  establish  an  Air  Force 
business  strategy,  jointly  maintained  and  promulgated  with 
the  VCSAF. 


•  Limited  understanding  of  AS-IS  environment 
and  early  supporting  analyses  preclude 
business  case  rigor  before  IT  acquisition. 


Document  an  integrated  AS-IS  environment  at  the  Air  Force 
enterprise  level.  This  provides  the  baseline  for  functional 
strategies  and  transformations,  and  ensures  coordination 
across  functions  leading  to  integrated  solutions. 

With  the  AS-IS  baseline  established,  develop  metrics  to 
measure  progress  toward  the  TO-BE  environment. 
Benchmarking,  simulation,  and  even  small  pilot  programs 
can  help  develop  these  metrics. 

Link  benefits  with  specific  changes  to  business  processes, 
organizations,  and  IT  to  improve  the  business  case’s 
foundation.  This  would  foster  a  complete  consideration  of 
benefits,  costs,  and  risks. 


•  There  are  disincentives  to  articulating 

benefits  and  reporting  their  realization  (e.g., 


Establish  accountability  to  the  Air  Force  Corporate  Structure 
for  benefits  realization.  Use  achieving  the  benefits  in  the 
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Challenges 


Recommendations 


financial  and  personnel  savings). 


•  Multiple  Air  Force  stovepipes  (functional, 
business,  and  command)  inhibit  timely, 
effective,  and  efficient  transformation. 


•  Public-sector  governance  has  oversight 
dictated  by  law  with  mandatory  compliance — 
or,  in  the  case  of  regulations  and  policies, 
waiver  requests. 


•  Instability  due  to  senior  leadership  transience 
impairs  effective  decisionmaking. 


•  The  absence  of  an  overarching  business 
strategy  has  hindered  the  evolution  and 
convergence  of  financial,  logistics,  and 
human  resources  systems  and  processes 
and  has  resulted  in  program  decisions  that 
require  changes  to  other  ERP  systems. 

•  Difficulty  in  driving  changes  to  business 
process  and  minimizing  unnecessary 
customization. 


•  Competing  stakeholder  priorities  are  not 
aligned  to  goals  and  benefits  documented  in 
the  business  case. 


•  Air  Force  OCM  often  too  narrowly  focused, 
underfunded,  or  mistimed,  leading  to 
inaccurate  or  unrealistic  expectations. 


funding  decisions  within  the  PPBE. 

Consider  benefits-sharing  with  stakeholders  to  incentivize 
better  disclosure  and  management  of  benefit  realization. 

The  Air  Force  CMO  (USECAF)  should  establish  an  Air  Force 
business  strategy,  jointly  maintained  and  promulgated  with 
the  VCSAF.  This  will  provide  the  foundation  for 
decisionmaking  necessary  to  address  touchpoints  between 
stovepipes. 

Question  rationales  for  management  layers  based  on 
regulations  and  policies  and  reduce  them  to  minimize  the 
distance  of  the  decisionmaker  from  the  issues.  This  should 
reduce  opportunities  for  information  to  be  filtered,  distorted, 
or  misrepresented  and  increase  probability  that  decisions  are 
addressing  the  correct  issue. 

Documenting  governance  authorities,  roles,  and 
responsibilities  in  a  charter  helps  increase  opportunity  for 
continuity. 

Make  the  USECAF  and  VCSAF  co-chairs  of  Air  Force 
enterprise  governance. 

Report  benefits  realization  at  CORONA  or  another  executive 
forum,  ensuring  the  Air  Force’s  senior  stakeholders  are 
involved.  As  decisions  at  this  level  are  documented,  a  record 
is  maintained  for  continuity. 

Use  the  Air  Force  enterprise  business  strategy,  business 
enterprise  architecture,  to  be  the  framework  and  foundation 
for  BPR  and  technology  decisions,  including  cross-functional 
decisions. 


Starting  from  the  documented  AS-IS  processes,  conduct 
BPR  and  develop  TO-BE  business  processes  before 
determining  if  a  new  IT  acquisition  is  appropriate. 

Question  and  attempt  to  mitigate  constraints  on  BPR  based 
on  regulations  and  policies. 

Use  the  decisionmaking  criteria  grounded  in  the  business 
case  to  provide  objective  criteria  to  decide  between  changing 
processes  or  customizing  technology. 

Use  the  promulgated  Air  Force  business  strategy  to  focus 
stakeholder  priorities. 

Explore  various  forms  of  incentives;  performance 
evaluations,  promotion  opportunities,  and  allure  of  new  roles 
have  been  successful  in  other  DoD  ERP  programs. 

Adequately  fund  OCM  activities,  and  carefully  schedule 
these  activities  to  mesh  with  the  transformation  timeline. 

Initial  OCM  activities  focus  on  senior  leader  education  and 
buy-in. 

Later  activities  focus  on  acceptance  of  new  technology  and 
process/organization  changes. 

As  key  decisions  are  made  that  affect  the  trajectory  of  the 
overall  transformation,  stakeholder  analyses  and  OCM  plans 
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Recommendations 


Challenges 


(communication,  education,  and  training)  should  be  updated. 


•  Stakeholder  analyses  are  not  robust  enough 
and  generally  not  considered  in  finalization  of 
the  business  case. 


A  stakeholder  analysis  is  necessary  to  identify  potential 
organizational  pitfalls  and  the  feasibility  of  achieving  desired 
benefits  within  a  proposed  timeline.  The  analysis  should  be 
updated  as  the  effort  evolves. 


•  DoD  ERP  programs  don’t  lend  themselves  to 
generalized  solutions  because  each  presents 
different  opportunities,  risks,  and  competing 
priorities. 


Conduct  a  robust  AoA  to  assess  alternative  approaches  to 
achieving  enterprise  objectives  specified  in  the  business 
case.  The  analyses  should  address  appropriate  system 
scope,  functional  complexity,  required  interfaces,  data 
quality,  and  key  constraints. 

IT  should  be  delivered  in  manageable  increments 
considering  complexity,  operational  priorities  (e.g., 
auditability,  legacy  system  retirement),  implementing  basic 
functionality  before  extensions,  complete  end-to-end 
processes  where  feasible,  and  coordinating  with  related 
initiatives  (e.g.,  reorganization,  replacement  or  upgrades  of 
legacy  systems,  changes  in  hosting  environment). 

A  robust  assessment  of  data  sources,  structures,  definitions, 
and  quality  should  be  conducted  early  on  to  inform  both  BPR 
and  IT  planning  activities. 


•  Expertise  in  ERP  and  business  processes 
not  consistently  available. 


Ensure  qualified  personnel  are  involved  with  the  program 
either  through  assignment  or  contracting  arrangements. 


Pretransformation 

•  Promulgate  and  implement  a  sufficiently  detailed  Air  Force  enterprise  business  strategy 
that  comprises  the  elements  previously  described  and  create  a  business  enterprise 
architecture  to  be  the  framework  and  foundation  for  future  business  transformations.  This 
also  provides  the  framework  for  understanding  the  AS-IS  and  TO-BE  environments.  The 
business  strategy  should  be  developed  by  the  CMO  (USECAF),  and  infonned  and  jointly 
promulgated  by  the  VCSAF.1  As  depicted  by  the  blue  arrows  in  Figure  7.1,  functional 
strategies  should  flow  from  the  Air  Force  enterprise  business  strategy  and  are  the 
motivation  for  the  functional  transformations.2  The  green  arrows  indicate  the  functional 
transformations  that  enable  the  associated  strategies,  which  in  turn  enable  the  Air  Force’s 
total  transformation.  The  orange  horizontal  arrows  indicate  cross-functional  coordination 
and  integration.  The  purple  arrows  show  the  connection  of  the  enablers  to  the  desired 
transformations. 

•  Document  an  integrated  AS-IS  environment  at  the  Air  Force  enterprise  level.  This 
provides  the  baseline  for  functional  strategies  and  transformations  and  ensures 
coordination  across  functions  leading  to  integrated  solutions. 

•  With  the  Air  Force  business  strategy  as  the  foundation,  establish  Air  Force  enterprise- 
level  governance  chaired  by  the  USECAF  and  VCSAF.  The  business  and 


1  This  complements  the  USECAF’s  and  VCSAF’s  responsibilities  (Under  Secretary  of  the  Air  Force,  May  2012). 

2 

This  would  also  apply  to  other  business  functional  strategies  and  transformations  not  shown. 
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command/operations  parts  of  the  Air  Force  are  now  represented  and  the  decisionmakers 
can  make  integrated,  cross-functional  decisions  to  optimize  the  Air  Force  enterprise. 

•  Provide  an  assessment  of  compliance  with  Air  Force  business  strategy  at  an  executive 
forum,  preferably  CORONA.3  The  four-star  stakeholders  are  then  directly  involved  in  Air 
Force  business  benefits  realization.  CORONAs  have  the  benefit  of  being  existing, 
ongoing  meetings,  so  discussions  in  this  venue  would  reduce  the  impact  of  senior 
leadership  turnover  and  increase  business  program  stability.  It  also  would  increase 
accountability  in  implementing  Air  Force  business  strategy. 


Figure  7.1.  Relationship  of  Enterprise  Business  Strategy  to  Functional  Transformation 


Transformation,  Preprogram  Initiation 

•  Develop  a  business  case  consistent  with  enterprise  strategy  and  goals  that  is  aligned  with 
lower-level  Air  Force  business  and  IT  enterprise  architectures.  In  building  the  business 
case,  the  Air  Force  must  place  a  greater  emphasis  on  expected  benefits  and  their 
realization. 

-  With  the  AS-IS  baseline  established,  develop  metrics  to  measure  progress  toward 
the  TO-BE  environment.  Benchmarking,  simulation,  and  even  small  pilot 
programs  can  help  develop  these  metrics. 

-  Establish  accountability  to  the  Air  Force  Corporate  Structure  for  benefits 
realization.  Funding  decisions  within  the  PPBE  should  factor  in  achievement  of 
benefits. 

-  Consider  benefits-sharing  with  stakeholders  (e.g.,  allowing  stakeholders  to  retain 
a  portion  of  saved  funds  or  manpower)  as  an  incentive  for  better  disclosure  and 
management  of  benefit  realization. 


3 

CORONA  meetings  are  held  three  times  a  year  to  provide  a  venue  for  the  most  senior  leadership  of  the  Air  Force  to 
consider  important  service-wide  issues.  These  meetings  are  chaired  by  the  SECAF  and  CSAF. 
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-  Link  benefits  with  specific  changes  to  business  processes,  organizations,  and  IT  to 
improve  the  business  case’s  foundation.  This  would  foster  a  more  complete 
consideration  of  benefits,  costs,  and  risks. 

•  Once  a  decision  is  made  to  go  forward,  develop  the  transformation  governance  structure 
for  decisionmaking  that  advances  the  transformation  goals.  This  needs  to  be  done  within 
the  context  of  the  Air  Force  business  strategy  and  should  be  aligned  with  the  Air  Force 
enterprise  business  governance,  which  is  responsible  for  advancing  this  strategy  and 
should  be  co-chaired  by  the  USECAF  and  VCSAF. 

-  Governance  should  be  documented  and  be  based  on  achieving  the 
transformation’s  goals  and  objectives  as  stated  in  the  business  case.  This 
establishes  a  baseline  with  all  the  stakeholders  early  in  the  transformation, 
allowing  them  to  take  an  enterprise  view  before  more  specific  interests  surface, 
and  forms  a  foundation  for  decisionmaking  criteria  that  will  help  guide  the  rest  of 
the  project  toward  achieving  the  stated  goals. 

-  Authorities,  roles,  and  responsibilities  must  be  written  in  an  unambiguous, 
enforceable  charter. 

-  Rationales  for  management  layers  based  on  regulations  and  policies  should  be 
questioned  and,  where  possible,  reduced  to  minimize  the  distance  of  the 
decisionmaker  from  the  issues.  This  should  reduce  opportunities  for  information 
to  be  filtered,  distorted,  or  misrepresented  and  increase  probability  that  decisions 
are  addressing  the  correct  issue. 

•  Starting  from  the  documented  AS-IS  processes,  conduct  BPR  and  develop  TO-BE 
business  processes  before  determining  if  a  new  IT  acquisition  is  appropriate.  This  helps 
ensure  that  process  goals  are  clearly  understood  and  provides  definitive  information  to 
assist  in  determining  the  correct  materiel  solution  if  one  is  necessary. 

-  Question  and  attempt  to  mitigate  constraints  on  BPR  based  on  regulations  and 
policies. 

-  If  a  new  IT  materiel  solution  is  required,  update  the  TO-BE  processes  and 
reassess  benefits  realization. 

•  OCM  activities  should  begin  once  the  decision  is  made  to  pursue  a  business 
transformation.  These  activities  should  be  adequately  funded  and  carefully  timed  to  the 
transformation. 

-  The  business  case  provides  key  objectives  and  expected  changes  that  leadership 
and  OCM  personnel  need  to  communicate.  The  business  case  will  help  OCM 
personnel  articulate  a  convincing  argument  for  change,  thus  fostering  buy-in  and 
early  understanding.  Senior  leaders  need  to  understand  where  and  why  their 
involvement  is  required.  Functional  personnel  involved  with  data-cleansing 
efforts  and  BPR  should  understand  and  internalize  the  business  case  objectives 
and  how  these  specific  efforts  fit  in  the  larger  picture. 

-  A  stakeholder  analysis  is  necessary  to  identify  potential  organizational  pitfalls  and 
the  feasibility  of  achieving  desired  benefits  within  a  proposed  timeline.  This 
analysis  should  assess  equities  and  priorities  of  all  affected  stakeholders,  in 
addition  to  their  commitment,  perceptions,  and  concerns  with  respect  to  the  effort. 
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•  Data  quality  was  noted  by  many  of  our  sources  to  be  more  of  a  challenge  than  originally 
planned  for.  They  found  that  different  legacy  systems  used  different  data  definitions  for 
the  same  or  similar  data,  different  systems  needed  different  data,  and  migrating  this  to  a 
new  IT  system  took  substantially  more  time  and  effort  than  anticipated.  A  robust 
assessment  of  data  sources,  structures,  definitions,  and  quality  should  be  conducted  early 
in  the  process  to  inform  both  BPR  and  IT  planning  activities. 

Transformation,  Post-Program  Initiation 

•  Governance,  using  criteria  founded  in  the  business  case,  should  be  employed  to  decide 
whether  changing  the  updated  business  processes  or  customizing  the  system  is  more 
appropriate.  For  an  ERP,  literature  and  best  practices  indicate  it  is  typically  preferable  to 
modify  processes  as  this  preserves  the  integrated  nature  of  the  ERP  system  and  has  less 
cost  and  schedule  impact.  This  may  not  be  the  case  for  other  technologies. 

-  The  decisionmaking  criteria  must  be  consistent  from  the  program  level  to  the  Air 
Force  enterprise  level.  With  these  criteria  understood  well,  objective 
decisionmaking  can  increase  the  likelihood  that  the  program  will  achieve  the 
benefits  described  in  the  business  case. 

•  Program-specific  OCM  should  focus  on  achieving  acceptance  of  the  new  technology  and 
required  process/organizational  changes;  this  is  frequently  accomplished  by  providing 
incentives  to  affected  personnel. 

-  Middle  managers’  participation  in  planning  and  preparing  for  an  ERP 
implementation  will  equip  them  with  valuable  experiences  and  broader 
perspectives  on  business  operations.  This  added  experience  could  qualify  them  for 
promotion. 

-  Including  an  assessment  of  individuals’  support  of  the  new  goals  and  objectives  in 
their  performance  reviews  can  also  be  a  good  incentive. 

-  New  roles,  such  as  the  ability  to  manage  one’s  own  portfolio,  may  also  help  boost 
cooperation. 

-  Some  retirees,  due  to  their  knowledge  and  perspective,  may  be  effective 
influencers  “behind  the  scenes.”  If  enough  of  these  individuals  support  the  effort, 
their  attitudes  can  affect  those  still  in  service. 

•  As  key  decisions  are  made  that  affect  the  trajectory  of  the  overall  transformation, 
stakeholder  analyses  and  OCM  plans  (communication,  education,  and  training)  should  be 
updated. 

•  Conduct  a  robust  AoA  to  assess  alternative  approaches  to  achieving  enterprise  objectives 
specified  in  the  business  case.  The  analyses  should  address  appropriate  system  scope, 
functional  complexity,  required  interfaces,  data  quality,  and  key  constraints. 

•  IT  should  be  delivered  in  manageable  increments  considering  complexity,  operational 
priorities  (e.g.,  auditability,  legacy  system  retirement),  implementing  basic  functionality 
before  extensions,  complete  end-to-end  processes  where  feasible,  and  coordinating  with 
related  initiatives  (e.g.,  reorganization,  replacement  or  upgrades  of  legacy  systems, 
changes  in  hosting  environment). 

•  Effective  IT  implementation  requires  personnel  with  in-depth  knowledge  of  functional 
operations  and  others  with  relevant  technology  experience.  If  an  ERP  is  the  desired 
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solution,  true  ERP  SMEs  are  needed  to  guide  its  implementation  due  to  its  complexity 
and  to  meet  schedule  constraints.  This  expertise  can  either  be  organic  or  provided  by 
contractors  who  act  as  trusted  agents  of  the  government  and  are  not  affiliated  with  the 
implementing  vendor.  Having  individuals  leam  these  skills  on  the  job  or  using  a  rotating 
cast  of  key  personnel  increases  cost  and  schedule  risk. 
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Appendix  A.  Planning  Activities 


In  this  appendix,  we  provide  a  high-level  summary  of  planning  activities  that  must  occur  to 
successfully  carry  out  ERP-enabled  business  transformation.  These  activities  are  organized  in 
Table  A.  1  horizontally  by  temporal  phase  and  vertically  by  planning  area. 

The  Pretransformation  phase  represents  what  should  take  place  to  perform  “business  as 
usual.”  Many  of  the  activities  that  take  place  during  the  Pretransformation  phase  should  continue 
through  the  other  two  phases.  Transformation  begins  at  the  point  where  a  problem  is  recognized 
that  cannot  be  addressed  through  routine  management  techniques  (therefore  requiring  a 
transformation).  Program  Initiation  is  defined  as  the  point  where  it  is  decided  that  IT  acquisition 
will  be  needed  to  achieve  transformational  goals.  In  the  Defense  Acquisition  System,  this  is  the 
MDD  milestone.  Pretransformational  activities  do  not,  in  many  cases,  fit  neatly  within  the 
planning  areas  as  described  in  this  report.  However,  each  of  these  activities  roughly  corresponds 
to  a  particular  planning  area,  as  depicted  in  Table  A.  1 . 

Planning  activities  are  also  described  within  the  context  of  three  tiered  perspectives: 
enterprise  view,  transformational  view,  and  program  view.  The  enterprise  view  focuses  on  issues 
affecting  the  entire  Air  Force  enterprise  and  is  within  the  purview  of  top  leadership  (i.e.,  SECAF, 
USECAF  (CMO),  CSAF,  and  VCSAF).  The  transformational  view  focuses  on  issues  relating  to 
a  specific  transformational  initiative  within  the  enterprise,  and  usually  corresponds  to  a  particular 
functional  community  or  command.  The  program  view  pertains  to  the  IT  acquisition  activities 
that  are  part  of  the  transfonnational  initiative  and  are  within  the  purview  of  the  program’s  FMO 
or  PMO. 

This  appendix  may  be  helpful  as  a  supplement  to  Appendix  B,  which  is  intended  for  use  as  a 
program  assessment  tool. 
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Table  A.1.  Planning  Activities  by  Temporal  Phase  and  Planning  Area 


Transformational  Pretransformation  Transformation,  Transformation, 

Planning  Area  (i.e.,  Ongoing)  Preprogram  Initiation  Post-Program  Initiation 


ECHELON  LEGEND:  Enterprise  View,  Transformational  View,  Program  View 


Business  Case 


Use  enterprise  goals  and 
objectives  articulated  in 
Air  Force  business 
strategy  to  develop 
enterprise  architectures. 
Monitor  external/internal 
business  drivers  and 
need  for  transformation. 
Maintain  derived 
functional/command  goals, 
strategies,  and 
architectures. 

Monitor  external/internal 
business  drivers  and  need 
for  transformation. 


Build  business  case  for 
transformation: 
o  Identify  goals;  define 
derived  benefits;  and 
assess  associated  cost, 
schedule,  and  risk  of 
alternatives, 
o  Governance, 
businesses  processes, 
organization,  and  IT 
issues  should  all  be 
considered. 

o  If  IT  acquisition  needed, 
then  submit  BCL 
problem  statement  at 
MDD. 


Carry  out  AoA  to  help 
determine  preferred 
solution  if  IT  acquisition  is 
needed. 

o  Governance, 

businesses  processes, 
organization,  and  IT 
issues  should  all  be 
considered. 

Summarize  analyses  in 
BCL  business  case  and 
submit  before  Milestone  A. 


Governance 


Implement  enterprise 
governance  board 
(co-chaired  by  USECAF 
and  VCSAF). 
o  Decisionmaking 
criteria  based  on  Air 
Force  enterprise 
strategy  to  achieve 
enterprise  goals. 


Early  on,  create 
governance  board  at  the 
appropriate  level  to  support 
upcoming  transformation 
necessary  to  achieve 
enterprise  goals, 
o  Use  stakeholder 
analysis  to  determine 
the  participants  and 
level  of  influence. 

Use  functional/command 
strategy  to  develop 
decisionmaking  criteria. 


Align  program  governance 
with  enterprise 
governance  and  focus 
program-level  governance 
on  achieving  business 
case  benefits. 

Focus  decisions  on 
changing  processes  or 
customizing  technology  to 
support  goals  and  achieve 
business  case  benefits. 
Support  enterprise  and 
transformational-level 
governance. 
o  Provide  requested 
information  to  allow 
governance  to  decide 
between  changing 
processes  or 
customizing  technology. 
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Transformational 
Planning  Area 


Pretransformation 
(i.e.,  Ongoing) 


Transformation, 
Preprogram  Initiation 


Transformation, 
Post-Program  Initiation 


Business  Process 
Reengineering 


Maintain  cost  and 
performance  data  for 
business  operations. 
Continually  improve 
business  processes  at 
enterprise  levels, 
independent  of  IT. 
Develop  high-level  AS-IS 
process  model. 
Continually  improve 
business  processes  at 
functional  levels, 
independent  of  IT. 


Develop  high-level 
TO-BE  solutions, 
o  BPR  team  and 
executive  steering 
committee  choose 
alternatives  and 
supporting  IT,  if  any. 
Develop  and  understand 
enterprise  level  TO-BE 
business  processes,  while 
questioning  operating 
constraints. 

Support  establishment  of 
BPR  team. 

Develop  detailed  AS-IS 
process  model, 
o  Develop  candidate 
alternative  TO-BE 
solutions. 

Work  with 

functional/command  to 
improve  AS-IS  process 
model. 

o  Work  with 

functional/command  to 
develop  candidate 
alternative  TO-BE 
solutions. 


Fit-gap  analysis. 
Blueprinting. 
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Transformational 
Planning  Area 


Pretransformation 
(i.e.,  Ongoing) 


Transformation, 
Preprogram  Initiation 


Transformation, 
Post-Program  Initiation 


OCM 


If  a  more  transparent, 
integrated,  or  efficient 
organization  is  desired, 
work  to  establish  a 
culture  that  values 
enterprise  goals  over 
stovepiped  goals  (may 
involve  a  reexamination 
of  incentive-structures 
and  policies). 

Train  people  well  on  job 
functions. 

Educate  employees  on  how 
their  role  fits  into  enterprise 
mission. 


•  Leadership  should 
visibly  communicate 
support  for 

transformation  in  a  way 
that  is  consistent  with 
the  vision  as  defined  in 
the  business  case. 

•  Top-level  governance 
body  should  be  aware  of 
organizational  sticking 
points  (awareness 
achieved  through  a 
stakeholder  analysis) 
and  understand  their  role 
in  mitigating  potential 
issues. 

•  Begin  OCM  engagement 
with  leadership  on 
enterprise  goals  to  support 
business  case  and  BPR 
(includes  education). 

•  Perform  a  stakeholder 
analysis  to  determine 
organizational  challenges. 

•  As  early  as  possible,  train 
and  communicate 
expectations  and  goals  to 
those  who  will  be  involved 
in  transformational  efforts 
such  as  BPR,  data 
improvement,  decision 
groups,  etc. 

•  Communicate  early  and 
often  with  affected 
communities  regarding 
goals,  scope,  and  progress 
of  the  effort. 

•  Train  and  educate 
communities  on  changes  to 
take  place  as  a  result  of 
BPR,  data  improvement, 
and  other  transformational 
efforts. 


•  Leadership  should 
visibly  communicate 
support  for  the  addition 
of  a  new  technology 
solution  as  part  of  the 
transformational 
strategy. 

•  Top-level  governance 
body  needs  to 
understand  where  and 
why  time  and  attention 
will  be  needed  in 
program  decisions. 

•  Update  stakeholder 
analysis  (continue  to 
update  if  major  changes 
made  to  transformational 
objectives/plans). 

•  Continue  to  update 
communications, 
education,  and  training 
plans,  strategies,  tools, 
and  material.  Updates 
should  consider  decisions 
as  they  are  made  and  the 
results  of  the  stakeholder 
analysis  as  it  is  updated. 

•  Focus  OCM  activities  on 
acceptance  of  technology 
and  associated 
process/organizational 
changes. 

o  Enabled  through 
effective  use  of 
incentives  (e.g., 
performance 
appraisals). 
o  Set  and  manage 
reasonable  expectations 
regarding  early  system 
performance  through 
communications, 
education,  and  training 
(e.g.,  convey  that  a 
stabilization  period  is 
normal  for  an  ERP 
implementation). 
o  Coordinate  closely  with 
the  PMO  to  ensure 
proper  coordination  and 
timing  of  OCM  activities 
with  the  acquisition 
schedule. 

•  Inform  PMO  of  relevant 
results  of  the  stakeholder 
analysis  (to  be  considered 
when  determining  roll-out 
strategy,  etc.). 
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Transformational 

Pretransformation 

Transformation, 

Transformation, 

Planning  Area 

(i.e.,  Ongoing) 

Preprogram  Initiation 

Post-Program  Initiation 

Technology 

•  Document  current  IT 

•  Assess  data  to  be 

• 

Implement  system  in 

Acquisition 

baseline  including 

migrated;  begin  cleansing 

manageable  increments 

functions,  data,  interfaces, 

before  program  initiation  if 

considering: 

environment,  and  direct 

needed. 

o  Domain  and 

and  indirect  costs. 

•  Identify  and  characterize 

organizational 

range  of  IT  options  to  meet 

complexity 

enterprise  goals. 

o  Operational  payoff 
o  Core  functions  before 

extensions 

o  End-to-end  processes 
o  Related  external 

initiatives 

• 

Expand  process  blueprint 
to  fit  chosen  system 
alternative. 

• 

Identify  and  develop  plan 
for  providing  any  required 
functionality  not  available 
in  chosen  alternative. 

• 

Source  selection/contract 
award. 

• 

Configure/develop  system. 

• 

Test  increment. 

• 

Conduct  system  training. 

• 

Migrate  data. 

• 

Deploy  increment. 

• 

Sustain  system. 
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Appendix  B.  Implications  for  Program  Assessment 


In  this  appendix,  we  draw  upon  the  work  in  this  report  to  fonnulate  a  set  of  criteria  to  support 
early  program  assessments.  The  questions  contained  in  the  following  questionnaire  are  intended 
to  direct  the  analyst  to  potential  areas  of  risk  or  noncompliance  with  policy,  as  well  as  to 
conditions  for  success.  These  considerations  are  discussed  in  more  detail  in  Chapters  Two 
through  Six,  which  we  urge  analysts  to  reference  when  using  this  assessment  tool. 

This  list  is  not  sequential.  For  a  rough  chronological  view  of  activities,  refer  to  Appendix  A. 

Business  Case 

As  of  this  writing,  DoD  IT  acquisition  policy  and  guidance  for  the  business  case  (including  the 
problem  statement)  is  summarized  in  the  following  references:  Carter  (2011),  Defense 
Acquisition  Guidebook  (2012b),  and  Business  Case  Template  (2012a).  See  Chapter  Two  of  this 
report  for  a  more  detailed  discussion  of  business  case  considerations. 

•  Do  the  format,  content,  and  timing  of  the  business  case  (including  the  problem 
statement)  comply  with  DoD  IT  acquisition  policy  and  guidance? 

The  problem  statement  is  the  front-end  portion  of  the  business  case.  It  should  clearly  describe 
the  business  need  and  include  AS-IS  and  initial  TO-BE  analyses,  as  well  as  a  recommended 
course  of  action.  Guidance  for  the  format  and  content  of  the  problem  statement  is  summarized  in 
Defense  Acquisition  Guidebook  (2012b)  and  Business  Case  Template  (2012a).  It  is  important 
that  the  problem  statement  be  submitted  prior  to  MDD,  as  required  by  DoD  policy  (Carter, 

2011),  because  it  should  inform  the  decision  whether  to  pursue  a  materiel  solution.  If  a  materiel 
solution  is  needed,  a  business  case  is  subsequently  developed  that  builds  upon  the  problem 
statement.  The  business  case  justifies  the  recommended  course  of  action,  of  which  the  materiel 
solution  is  part.  While  the  business  case  is  a  living  document  that  is  refined  throughout  the  BCL 
lifecycle,  it  is  important  that  the  initial  business  case  is  submitted  prior  to  Milestone  A,  as 
required  by  DoD  policy  (Carter,  2011).  This  ensures  that  the  business  case  fulfills  its  purpose  of 
justifying  the  investment  of  resources  for  the  transformation  approach,  including  the  initiation  of 
an  acquisition  program.  The  remainder  of  this  appendix  further  helps  to  ensure  that  there  is 
sufficient  rigor  in  the  business  case.  In  addition  to  justifying  the  transformation  approach,  it  helps 
manage  the  realization  of  the  transformation  benefits. 

•  Are  the  motivating  enterprise  business  goals  identified  and  aligned  with  an  Air 
Force  business  strategy? 

As  explained  in  Chapter  Two  under  “Conditions  for  Success  .  .  .  Alignment  Between 
Enterprise  Business  Goals  and  Strategy,”  the  importance  of  setting  goals  explicitly  aligned  with 
enterprise  strategy  is  critical  for  ERP-enabled  business  change  because  it  provides  guidance  for 
governance,  BPR,  and  OCM  activities  involving  diverse  stakeholders  who  often  have  conflicting 
goals  and  priorities.  Moreover,  explicit  alignment  with  an  enterprise  strategy  fosters 
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compatibility  and  avoids  duplication  with  other  business  change  initiatives  being  carried  out 
within  the  enterprise.  Per  DoD  IT  acquisition  policy  and  guidance,  the  identification  of  business 
goals  and  their  alignment  with  strategy  are  required  to  be  included  in  the  problem  statement. 

•  For  each  solution  alternative  considered,  has  a  comprehensive  set  of  business 
benefits,  tied  to  the  stated  Air  Force  enterprise  business  goals,  been  identified? 

The  business  case  should  summarize  the  results  of  the  AoA,  which  occurs  just  after  MDD. 
The  basis  for  the  AoA,  and  thus  for  the  business  case,  should  be  a  comprehensive  list  of  business 
benefits  in  addition  to  cost,  schedule,  and  risk.  Differentiating  among  alternatives  with  respect  to 
benefits  can  be  challenging,  but  failing  to  do  so  results  in  an  incomplete  AoA.  While  a 
comprehensive  set  of  business  benefits  should  be  articulated,  unplanned  benefits  can  arise  after 
the  IT  system  is  implemented  and  the  organization  better  understands  how  to  exploit  it  to  obtain 
business  value. 

•  For  each  of  the  benefits,  have  the  following  been  identified? 

-  metric  with  AS-IS  and  TO-BE  values  and  method  of  measurement;  or  clear 
criteria  for  evaluation  for  qualitative  benefits 

-  rationale  and  support  for  the  realism  of  the  TO-BE  values 

-  benefit  owner,  ideally  with  sufficient  incentive  and  influence,  to  help  ensure 
realization. 

As  explained  in  Chapter  Two  under  “Conditions  for  Success  .  .  .  Detailed  Definition  of 
Business  Benefit,”  business  benefits  should,  to  the  extent  possible,  be  expressed  in  measurable 
terms  in  the  business  case — even  using  metrics  requiring  subjective  assessment  (e.g.,  for 
workforce  morale) — and  include  AS-IS  and  TO-BE  values  and  a  method  for  measurement  to 
help  track  their  realization.  While  metrics  that  can  be  expressed  in  financial  terms  are  attractive 
in  that  they  may  be  aggregated  into  an  economic  analysis  along  with  project  costs,  the 
importance  of  nonfinancial  benefits  for  IT  systems,  such  as  ERPs,  should  not  be  discounted; 
they,  too,  can  provide  significant  business  value.  Note  that  providing  values  for  metrics  entails 
an  understanding  of  both  AS-IS  and  TO-BE  performance  and  cost,  which  may  require 
simulation/modeling  tools,  benchmarking,  or  pilot  implementations  if  the  underlying  benefit 
entails  a  new  activity  (Ward,  2006).  While  analyses  underlying  the  AS-IS  and  TO-BE  values 
would  not  be  included  in  the  business  case,  such  analyses  should  be  made  available  to  the  analyst 
to  verify  the  accuracy,  realism,  and  rationale  of  the  stated  metric  values. 

Each  benefit  should  also  have  an  “owner”  who  is  responsible  for  its  realization.  Ideally,  a 
benefit  owner  will  be  an  individual,  but  can  also  be  a  small  group  of  individuals,  who  receives 
the  benefit  and  therefore  has  an  incentive  to  help  ensure  that  it  is  realized.  In  addition,  the  benefit 
owner(s)  should  have  sufficient  influence  to  help  bring  about  its  realization. 

•  For  the  solution  alternatives  considered,  have  the  linkages  between  each  business 
benefit  and  enabling  activities  and  considerations — spanning  governance,  BPR, 
OCM,  and  IT  acquisition — been  identified?  Are  these  enabling  activities  accounted 
for  in  cost,  schedule,  and  risk  analyses? 
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As  explained  in  Chapter  Two  under  “Conditions  for  Success  .  .  .  Linkage  of  Benefits  to 
Enabling  Activities  and  Considerations,”  delivery  of  business  benefits  entails  a  set  of  enabling 
activities  and  considerations  that  span  governance,  BPR,  OCM,  and  IT  acquisition.  These 
activities  and  considerations  are  addressed  in  Chapters  Three  through  Six,  and  in  the 
questionnaires  in  the  subsequent  sections  of  this  appendix.  Linking  activities  with  benefits  is 
critical  because  it  provides  the  foundation  for  their  inclusion  in  cost,  schedule,  and  risk  analyses 
in  the  business  case,  thereby  supporting  the  justification  for  the  selected  course  of  action.  Such 
links  also  provide  the  foundation  for  managing  the  process  to  realize  benefits.  While  explicit 
linkages  to  individual  benefits  may  not  be  present  in  the  business  case,  supporting  analyses 
describing  the  linkages  should  be  made  available  to  the  analyst. 

•  Has  the  preferred  alternative  been  selected  according  to  an  analysis  of  business 
benefits  that  are  tied  to  (prioritized)  enterprise  business  goals,  in  view  of  cost, 
schedule,  and  risk? 

As  noted  in  Chapter  Two  under  “Conditions  for  Success  .  .  .  Comprehensive  Analysis  of 
Alternatives,”  once  the  set  of  alternatives  has  been  established,  the  basis  for  selecting  the 
preferred  alternative  should  be  an  assessment  of  the  business  value  offered  by  each  in  view  of  the 
associated  cost,  schedule,  and  risk.  As  explained  earlier,  characterizing  the  full  range  of  business 
benefits  offered  by  each  alternative  should  be  attempted.  Similarly,  the  full  range  of  costs, 
schedule  drivers,  and  risks  should  be  captured.  Often,  the  benefits  and  risks  for  alternatives  may 
be  dissimilar  in  kind,  which  requires  a  decisionmaker  to  employ  judgment  in  prioritizing  benefits 
and  risks.  This  informed  judgment  is  preferable  to  assuming  away  any  important  differences  in 
benefits  and  risk,  or  employing  a  methodology  that  does  not  adequately  capture  enterprise 
priorities. 

Governance 

See  Chapter  Three  for  a  more  thorough  discussion  of  governance  considerations. 

•  How  do  the  decisionmaking  criteria  support  the  strategy  and  business  case  and 
associated  benefits  realization? 

As  described  in  “Conditions  for  Success”  in  Chapter  Three,  the  decisionmaking  criteria  used 
within  the  governance  process  should  be  grounded  in  the  well-articulated  business  case 
(addressed  in  the  previous  section).  This  business  case  has  documented  objectives  and  desired 
benefits,  therefore  all  decisions  need  to  be  made  in  the  context  of  achieving  these  objectives  and 
benefits. 

•  How  has  the  governance  structure  been  optimized  to  maximize  decisionmaking 
effectiveness  and  efficiency? 

The  following  are  some  considerations  for  an  optimized  governance  structure: 

-  Authority  is  documented  and  supported  by  statute,  regulation,  policy,  or  official 
correspondence.  The  scope  of  decisionmaking  authority  is  well  defined,  and 
recourse  for  areas  outside  this  authority  is  established. 
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-  What  are  members’  roles  and  responsibilities?  Are  they  documented  in  an 
enforceable  charter? 

-  Who  is  the  ultimate  decisionmaker  and  what  is  his/her  tenure? 

-  If  decisionmaking  is  done  by  committee,  what  is  the  process  for  reaching 
decisions  in  a  timely  manner  that  will  move  the  activity  forward  without 
hindering  achievement  of  the  objectives  and  benefits  outlined  in  the  business 
case? 

-  If  the  governance  structure  contains  multiple  layers,  what  is  the  justification  for 
those  layers  (e.g.,  dictated  by  laws,  regulations,  and  policies)?  If  dictated  by 
regulations  or  policies,  can  they  be  waived  to  streamline  the  structure?  As 
described  under  “Challenges”  in  Chapter  Three,  cross-functional  governance 
structure  can  filter,  dilute,  or  otherwise  change  information.  This  potentially 
delays  critical  decisions  or  even  results  in  the  wrong  problem  being  addressed. 
Regardless,  either  case  could  adversely  affect  cost,  schedule,  and  benefits 
realization. 


Business  Process  Reengineering 

As  the  body  of  this  report  states,  the  most  critical  challenge  to  overall  BPR  project  success  is  not 
technical;  rather,  it  involves  the  human  and  behavioral  aspects  of  OCM  (Somers  and  Nelson, 
2001).  See  Chapter  Four  for  a  more  detailed  discussion  of  key  BPR  considerations,  such  as 
leadership  support  and  organizational  and  incentive  structures. 

•  Does  the  BPR  activity  have  visible  senior  leadership  support? 

•  Have  the  goals  and  objectives  of  the  BPR  activity  been  communicated  by  senior 
leadership? 

Even  when  a  particular  BPR  activity  is  taking  place  to  support  a  technological 
implementation,  this  communication  should  originate  from  functional,  not  acquisition, 
leadership. 

•  Do  BPR  teams  consist  of  members  representing  each  function  to  be  affected  by  the 
process  changes? 

Team  members  should  be  knowledgeable  enough  to  be  able  to  speak  authoritatively  on 
behalf  of  the  functional  community,  and  should  be  empowered  to  make  decisions  affecting  the 
processes  of  their  functional  community. 

•  Do  senior  leadership,  middle  management,  and  support  staff  have  sufficient 
knowledge  of  BPR? 

-  Has  leadership  set  realistic  expectations  for  BPR  activity? 

-  Are  there  individuals  available  to  the  project  team  with  an  understanding  of 
business  processes  at  an  enterprise  and  program  level? 

-  Are  there  individuals  available  to  the  project  team  with  knowledge  of  BPR 
methodology  and  practice? 

•  Were  the  AS-IS  and  TO-BE  processes  mapped  before  technology  selection?  Are 
they  aligned  with  the  DoD  and  Air  Force  business  process  architectures? 
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These  process  maps  should  be  included  in  the  BPR  Assessment  Package.  The  processes 
should  be  mapped  in  sufficient  detail  to  identify  root  causes  of  process  problems  in  the  AS-IS 
environment  and  the  corresponding  solutions  in  the  TO-BE  processes. 

•  Is  a  plan  in  place  to  use  metrics  to  manage/measure  process  improvements? 

Note  that  process  improvements  are  different  from  technical  improvements. 

•  Are  there  mechanisms  and  processes  in  place  to  minimize  unnecessary 
customization? 

Significant  customization  should  be  justified  by  a  business  case  demonstrating  enterprise- 
level  cost-benefit  analysis  approved  by  the  executive  steering  committee  (or  project  sponsor). 

Organizational  Change  Management 

See  Chapter  Five  for  a  more  detailed  discussion  of  key  OCM  considerations. 

•  Have  resources  been  identified?  Are  they  adequate  to  cover  the  following  activities? 

-  Stakeholder  analysis 

-  Communications  plans 

-  Training 

-  Education 

•  Are  OCM  activities  predominantly  ‘owned’  by  the  FMO? 

It  is  typical  for  some  OCM  activities  to  be  contracted  out.  However,  if  a  support  contractor  is 
employed  to  perform  OCM  activities,  the  contract  should  be  managed  and  overseen  by  the  FMO. 
In  general,  OCM  activities  should  ultimately  be  performed  by  the  functional  community. 

•  Was  a  thorough  stakeholder  analysis  done  before  finalization  of  the  business  case, 
before  program  initiation? 

-  Are  all  stakeholders  (external  and  internal)  included  in  the  analysis? 

-  Have  the  priorities  and  equities  of  each  stakeholder  been  identified? 

-  Does  the  analysis  consider  actual  levels  of  commitment,  attitudes,  or  beliefs  of 
each  stakeholder?  Some  level  of  awareness  of  commitment  and  attitudes  is 
necessary  to  anticipate  “sticking  points”  in  the  project/initiative. 

-  Are  resources  in  place  to  update  the  stakeholder  analysis  when  appropriate  (in 
response  to  key  decisions  that  change  the  trajectory  of  the  effort)? 

-  Have  the  stakeholder  analysis  and  organizational  constraints  been  considered 
when  finalizing  the  business  case  (particularly  when  detennining  feasibility  of 
and  strategy  for  achieving  desired  benefits)?  If  not,  feasibility  of  realizing  desired 
benefits  should  be  reexamined. 

•  Have  leadership,  decision  groups,  and  boards  been  adequately  educated  on  the 
nature  of  the  transformation  and,  if  necessary,  on  the  IT  system  to  be  adopted  and 
the  preparatory  activities  to  be  carried  out?  If  not,  are  there  plans  and  resources  in 
place  to  provide  such  education? 
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Leadership  should  understand  potential  pitfalls  and  best  practices.  Involvement  may  need  to 
be  more  intense  than  expected;  this  activity  should  help  leadership  understand  where  and  why 
their  support  and  time  is  needed. 

•  Are  resources  and  executable  plans  in  place  for  dealing  with  or  incentivizing 
unwilling  parties? 

It  is  difficult  to  predict  the  extent  of  possible  resistance,  but  plans  should  not  simply  assume 
compliance  from  all  communities  and  should  make  use  of  stakeholder  analysis  to  better 
anticipate  and  plan  for  resistance.  Successful  strategies  for  mitigating  resistance  could  include 
the  following  options: 

-  promotion  opportunities 

-  performance  reviews 

-  development  and  emphasis  on  new  roles  and  responsibilities. 

•  Is  the  communications  plan  well  planned,  with  adequate  resources? 

-  Are  multiple  vehicles  to  be  used  in  communications?  (Examples  may  include 
informational  websites,  webinars,  staff  meetings,  high-visibility  announcements 
and  editorials  by  leadership,  Q&A  sessions,  fact  sheets) 

-  Does  the  communications  plan  allow  for  feedback  from  anyone  in  the  affected 
community? 

-  Is  the  message  in  the  communications  plan  consistent  with  the  organization’s 
values  and  the  overall  objectives  of  the  initiative? 

-  Are  resources  adequate  for  this  production  and  dissemination?  (Oftentimes, 
contractors  will  aid  in  the  development  of  materials,  but  the  government  is 
responsible  for  production  and  dissemination.) 

•  Do  education  and  training  plans  address  all  of  the  following: 

-  training  and  orientation  for  those  involved  in  transformative  efforts  before  the 
onset  of  these  efforts  (e.g.  BPR,  data  quality  improvement) 

-  training  for  new  processes  to  be  implemented  following  BPR  activities  (if 
necessary)  and  system  deployment 

-  appropriate  professional  development  for  individuals  who  will  need  new  skills 
and  knowledge  to  perform  new  processes  or  duties 

-  technology  and  system  training  for  use  of  the  system’s  functionalities. 

IT  Acquisition 

The  information  contained  in  this  IT  acquisition  questionnaire  is  intended  to  direct  the  reader  to 
potential  areas  of  risk  bearing  further  examination.  This  is  intended  to  be  a  synopsis  of  the 
information  provided  in  Chapter  Six. 

•  Is  the  preferred  alternative  aligned  with  the  DoD  and  Air  Force  target  enterprise  IT 
architectures? 

•  Were  all  IT  options  fairly  evaluated  before  a  particular  solution  was  selected?  This 
is  typically  contained  in  the  AoA  (see  Chapter  Six  for  criteria). 
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-  How  closely  ranked  were  the  alternatives?  Were  there  key  assumptions  that,  if 
changed,  would  change  the  result?  If  so,  are  those  assumptions  still  valid? 

•  What  functional  and  organizational  boundaries  will  the  system  cross? 

-  Are  senior  functional  officials  representing  all  key  stakeholders  (and  empowered 
to  make  decisions  for  their  communities)  assigned  to  the  program  team? 

-  Are  there  conflicting  goals  or  priorities  among  the  key  stakeholders?  Are  these 
likely  to  be  resolved  without  disrupting  program  execution? 

•  How  complex  is  the  functional  domain? 

-  How  structured/standardized  are  the  processes  to  be  automated?  Processes 
common  among  other  users  of  the  software  (e.g.,  general  ledger)  should  require 
less  tailoring  and  testing  than  highly  variable  processes  (e.g.,  maintenance). 

-  In  how  many  similar  applications  has  the  chosen  software  been  used?  Was  the 
functionality  satisfactory?  Was  significant  customization  required? 

-  How  many  similar  applications  has  the  implementing  contractor  developed  and 
deployed?  Is  the  expertise  from  prior  projects  guaranteed  to  be  available  for  the 
current  program  (e.g.,  key  personnel  clauses,  strong  contractual  incentives,  etc.)? 

-  Will  the  chosen  system  have  all  functionality  required  or  will  extensions  or 
additional  applications  need  to  be  developed  or  added  to  meet  the  system 
requirements  (i.e.,  fit/gap  analysis)?  Have  the  requirements  and  feasibility  of 
these  extensions  or  additional  software  been  analyzed  and  included  in  program 
budgets  and  schedules? 

•  How  many  interfaces  to  external  systems  will  be  required? 

-  How  complex  are  these  interfaces?  Are  there  documented  interface 
specifications/agreements? 

-  Are  there  planned  changes  or  upgrades  to  these  systems  that  might  affect  the 
current  system  design?  Upgrades  to  external  systems  may  require  changes  to  the 
program  of  interest,  delay  testing,  and  possibly  introduce  concurrency  risk. 

•  Has  the  data  quality  of  the  legacy  and  trading  partner  systems  been  assessed? 

-  Is  there  a  specific  action  plan  for  data  cleansing  (e.g.,  standardized  data  element 
definitions  or  formats,  funded  data  cleansing  effort  by  data  owner  or  program 
office)? 

•  What  are  the  key  limitations  of  the  legacy  system?  This  should  be  documented  in 
business  case. 

-  How  will  the  new  system  address  these  limitations?  (E.g.,  if  the  objective  is 
auditability,  will  the  new  system  and  its  data  sources  be  compliant  with  audit 
standards?  If  not,  have  courses  of  action  and  their  likely  impact  on  cost  and 
schedule  been  identified?) 

•  Is  the  plan  for  phasing  releases  and  increments  logical  and  executable? 

-  Does  it  consider  complexity,  operational  priorities  (e.g.,  auditability,  retirement  of 
legacy  systems),  implementing  basic  functionality  before  extensions, 
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encompassing  complete  end-to-end  processes  where  feasible,  and  coordinating 
with  other  related  initiatives  (e.g.,  reorganization,  replacement  or  upgrades  of 
legacy  systems,  changes  in  hosting  environment)? 

-  If  there  is  overlap  in  key  activities  between  releases,  is  sufficient  qualified  staff 
available  to  execute  activities  in  parallel? 


•  Are  there  personnel  with  relevant  ERP  implementation  experience  committed  to 
work  with  the  FMO  and  PMO  on  planning,  implementation,  and  deployment? 
These  may  be  government  personnel  experienced  with  BPR  (for  FMO)  or  ERP  (for 
PMO)  in  other  organizations,  or  trusted  independent  experts  who  can  be  used  as 
advisers. 
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